Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
i386: Relocation incorrectly applied to GOT entry #52
Describe the bug
Tested with Hopper, IDA Pro, and Cutter, and all produce the expected result. It appears that Ghidra is performing the relocation on that GOT entry but it's doing so incorrectly.
This is caused by a bug in the ELFSymbol equals() and hashcode() methods. This bug surfaces when multiple symbol tables are present in the ELF binary and can impact the processing of the GOT, PLT, and relocation processing for any processor. A fix for this will be included in our next release.
referenced this issue
Mar 22, 2019
I installed the 9.0.1 on my x86_64 Ubuntu desktop, created a new project from scratch, and imported a shared object compiled for an ARMv7L target and am still seeing Ghidra get confused about what symbols are where due to the incorrect 0x10000 offset. When I compare the output of objdump for the same file and run the ARMv7L target itself, I can see that Ghidra has the disassembly for the function diminuto_cue_debounce correct, but because of the incorrect offset, it places it in the middle of an entirely different object module (diminuto_controller) and proceeds to interpret the variables as if they were in that module (e.g. "numerator" etc.), not in diminuto_cue. Remarkably, the decompile for diminuto_due_debounce seems reasonable. Maybe this is a different bug... but it sure seems like this bug. Here are links to my screen snapshots.
EDIT: I similarly analyzed the same shared object but compiled for two different x86_64 targets (one of which was the host on which I ran Ghidra) and both disassemblies seem correct; I don't see the incorrect offset and the disassembly interprets the variables correctly.