You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: