Open cblichmann opened 3 years ago
For reference: BinDiff b/153891410.
FWIW this issue seems specific to MIPS binaries - I had the same problem with MIPS eCos images.
Is there any known work around for this? Thanks in advance
Well, BinExport uses whatever the disassembler gives it. So on one hand, this should really be fixed in Ghidra, either by fixing its analysis/heuristics or manually by cleaning up the disassembly. A small script that highlights duplicate functions should be easy enough to come up with for this. On the other hand, like I already said above, BinExport should always produce a valid .BinExport file. So I will fix this in BinExport, too, at some point. But that likely means to just drop one duplicated functions. This may or may not be what you'd want, though, as we might drop the wrong one (and for BinExport there's no way to know which one is good).
Thank you for taking the time to respond to my question. I appreciate it.
I just want to bump this with a little additional information: I have the same problem with an ARM executable, so this is not restricted to MIPS
Oh, and I should point out that this happens when comparing 2 debug builds of closely related executables. Seems strange for Ghidra to get tripped up on that...
Encountered this same issue on AARCH64 binaries, still an issue on latest version.
When exporting the
busybox
binary from busybox_mips_ghidra_binexport.zip, the function_init
at address004028B0
is included twice in theflow_graph
field, causing BinDiff to fail:The root cause is Ghidra not properly handling
_init
, but the BinExport extension should always output a valid .BinExport.