Mach-O library calls not handled properly

[BlueAmulet]

Describe the bug I'm working with a 32bit mach-o file, in the assembly view I can see various libstdc++.6.dylib calls such as _ZNSolsEm which should be std::ostream::operator<<(unsigned long) It seems like Ghidra didn't handle any of the imports correctly, the __jump_table section is filled with garbage instructions and none of the functions there are demangled. In the assembler view, I only see mangled names, and in the decompiler view, I get a generic func_0x0005d251()

Expected behavior Library calls should be demangled and show up properly in both the assembler and decompiler views.

Screenshots If applicable, add screenshots to help explain your problem.

Environment:

• OS: Windows 10 64bit 2004 (19041.928)
• Java Version: Java 11
• Ghidra Version: 10.0-BETA
• Ghidra Origin: Official website

[ryanmkurtz]

Can you attach your binary?

[BlueAmulet]

Apologies for the close and open, accidentally clicked the button. Here is the binary x86binary.zip

[ryanmkurtz]

Thanks, we'll take a look.

[ryanmkurtz]

We are incorrectly performing relocations over top of the jump table. I am doing some redesign which will include a fix.

[ryanmkurtz]

The jump table corruption has been fixed in ac0d7f6d43dc88346f8450648251cba511f0ddff, but the demangling is still not happening because the symbols are not in the global namespace.