jgottula
commented
4 years ago @bgottula Make sure to give this a test run for me to make sure I didn't cause any runtime regressions. I did a basic "run the compiler on it" sort of "test", but that's about as far as I could go, given my lack of camera hardware here. (I suppose I could have run a stub program that loads libASICamera2.so but doesn't do actual camera operations, just to see if the fixer library inits properly and doesn't crash it, but meh.)
(Also, though I do have GCC ARM cross-compilers handy, I don't know of any convenient hardware off the top of my head to test run it on, so I couldn't really actually test that the ARMv8 stuff works properly either.)
bgottula
VigibotDev
I had a sudden realization after thinking about issue #50 for a little while, that the timeouts may actually have been happening due to libzwo_fixer screwing things up, because apparently it was under the very incorrect presumption that everything was detected properly and that it was running on an AMD64 system, and was therefore patching in AMD64 hook code at undoubtedly incorrect/random addresses in the libASICamera2.so ARMv8 library!
So, the first thing that needed correcting was to do proper architecture detection. Previously there was fairly rigorous detection of the ASI SDK version; however, nothing actually stopped the library from blissfully doing completely wrong things if it was running on a non-AMD64 machine. So now, there are preprocessor checks to categorize the machine the library is being compiled on, and either allow compilation to continue, or annoy the user with an error/warning message telling them that they're attempting to build for an architecture that doesn't actually have the necessary code support built in (including the actual offsets in the relevant platform's variation of the libASICamera2.so binary).
After that, I took a look at how the PLT is handled by the runtime dynamic linker on AArch64 vs how it's done on AMD64, and it's actually pretty similar. And given that it was trivial to locate the necessary offsets in the ARMv8 libASICamera2.so binary, I figured I would just go ahead and implement some multi-arch support into the library. So now it supports both AMD64 and ARMv8. (But not i386, ARMv5, ARMv6, ARMv7, or the Mac or Windows versions. The former four could probably be done pretty easily if the desire ever arose.)
Making the code simpler / more unified / more architecture-generic steered me toward altering the way I had been doing the PLT hooks. Previously I was doing a frankly somewhat boneheaded thing where I wrote a custom AMD64 asm stub over the PLT entry itself. I could have taken the same approach for ARMv8, but I'd have to do a separate asm implementation, and the ARM ISA instruction encoding is a gigantic pain in the ass (particularly because something ostensibly easy like "hey let's just load up a 64-bit immediate value into a register and then jump to it" requires like 7 steps because you can't fit very many bits into a fixed-size 32-bit instruction word). And there were other downsides too: the way I was doing it required me to flip the page protection flags on the memory whenever the hook was enabled or disabled, because the PLT stub itself is a code section with R-X permissions, and modifying the code requires RW-. (Oh and on ARM, unlike x86, doing self-modifying-code-type-stuff doesn't "just work", you have to actually explicitly make sure the L1 I$ and D$ synchronize properly and so forth.) Plus, I was doing some questionable things anyway like using memcpy to overwrite code, which is potentially problematic because there's no guarantee that memcpy isn't going to copy one byte at a time and temporarily put the code into a partially-overwritten state.
So now, I just take advantage of the fact that the PLT entries are already set to just do an indirect jump via their GOT PLT slot (which is in a data section that is already RW-), and I literally just do a single 64-bit atomic exchange operation to overwrite the pointer that's used for the indirect jump. I probably should have been doing this originally, but I think there were plausible reasons why I didn't want to do it. In any case, I think the new way is much simpler and less dumb overall.