Open RomanHargrave opened 7 years ago
Not exactly this, but a closely related issue: build flags.
So far I've determined that _LIBCPP_BIG_ENDIAN
is set (strange considering X86 is little-endian, though I may be misunderstanding something) - comparing the LibCXX source code for the __get_short_size
method and the matching disassembly in PAYDAY 2, they match up.
Likewise, _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
is not set - checking the long struct source code and __get_long_pointer
in PAYDAY 2 shows this.
It's odd that PAYDAY uses libcxx in the first place. It's entirely possible that the version they are using isn't standard, which could explain the _LIBCPP_BIG_ENDIAN business, depending on how you determined it to be set.
clang
and g++
seem to handle templates a bit differently, and since their Lua-to-C++ binding appears to make heavy use of them, maybe g++
didn't work and clang
did, and then decided to use LibCXX since they were using clang anyway?
Or maybe the game was ported by a contractor who had standardised on clang/libcxx for some other reason?
It might better our ability to modify PAYDAY at the low level if we knew exactly what version of libcxx the game is compiled with, and possibly even the exact commit.
While we can (somewhat) safely make assumptions about libcxx (e.g. function signatures and memory layout for non-internal functionality, like std::string) it would be even better if we could leverage information-specific details for the purpose of understanding inlined functions in payday and the like.