3 ms·

1) Byte align the value of hash_ptr.parm.v.p 2) Decrement hash_ptr.parm.v.p 3) hash_ptr.parm.v.p points to the return value of fpop(sst) commentary: 1) Hard

1) Byte align the value of hash_ptr.parm.v.p 2) Decrement hash_ptr.parm.v.p 3) hash_ptr.parm.v.p points to the return value of fpop(sst) commentary: 1) Hardware / variable type specific! aka can be 8, 16, 32, or 64 C can pack the bit representation in unaligned fasion. 2) Hardware dependent -- some do not permit operations on addresses!v 3) Looks like fpop(sst) returns an address containing value (vs. returns value) which impliess that lower, unused bits in address are being used for storage. short answer: OS and/or hardware may not permit non-zero values in lower, unused address. At hardware level, executable & data bits may be required to be in different locations.

sargstuff 5y ago
Learning c via pointers : https://learncodethehardway.org/c/ https://learncodethehardway.org/c/ Different topic of containing values in an address vs. storing values in address given by address number -> https://libcello.org/learn/a-fat-pointer-library https://libcello.org/learn/a-fat-pointer-library
sargstuff 5y ago
Assuming the license terms on the working binary allows decompilation; could use a disassembler to psudo C on the original binary and same hardware, new 32 bit compile (ideally with same compiler (gcc/clang/etc) used on original binary) Diff the resulting pseudo source code to see where things get interpreted differently. Then use compiler explorer on the "differences", https://godbolt.org/z/v4TdvE83b https://godbolt.org/z/v4TdvE83b open source decompile to pseudo-C: ghidra: ghidra-sre.org retdec: https://github.com/avast/retdec https://github.com/avast/retdec
- sargstuff 5y ago
  Evaluate how 'similar' the pseudo soure code is via source code plagerism detection tools.
  - sargstuff 5y ago
    use gcc -fdump-translation-unit switch compile old code, compile new code. compare the differenct between the old gcc AST against the new gcc AST (or differences between the AST's generated when different compile switches are used) Doesn't mean there aren't assembly language differeces, but will narrow things down.

sargstuff 5y ago

Learning c via pointers : https://learncodethehardway.org/c/ https://learncodethehardway.org/c/ Different topic of containing values in an address vs. storing values in address given by address number -> https://libcello.org/learn/a-fat-pointer-library https://libcello.org/learn/a-fat-pointer-library

sargstuff 5y ago

Assuming the license terms on the working binary allows decompilation; could use a disassembler to psudo C on the original binary and same hardware, new 32 bit compile (ideally with same compiler (gcc/clang/etc) used on original binary) Diff the resulting pseudo source code to see where things get interpreted differently. Then use compiler explorer on the "differences", https://godbolt.org/z/v4TdvE83b https://godbolt.org/z/v4TdvE83b open source decompile to pseudo-C: ghidra: ghidra-sre.org retdec: https://github.com/avast/retdec https://github.com/avast/retdec

sargstuff 5y ago
Evaluate how 'similar' the pseudo soure code is via source code plagerism detection tools.
- sargstuff 5y ago
  use gcc -fdump-translation-unit switch compile old code, compile new code. compare the differenct between the old gcc AST against the new gcc AST (or differences between the AST's generated when different compile switches are used) Doesn't mean there aren't assembly language differeces, but will narrow things down.