cmd/link: latest Mac otool does not understand where Go functions end #24706
Comments
Did we set the size of a function (as the symbol size) in the symbol table?
|
Where should we put it? I didn't see a "size" entry in Mach-O symbol table. |
I don't believe the Mac symbol table has any entry for sizes. Does this happen with host linking too? |
This also happens with host linking. Host-linked binary has symbol table in address order, but apparently it doesn't help. I'll try to find out something from LLVM source. |
Reading llvm-objdump source code, apparently it thinks all our function symbols are in DATA section, because our __text section does not have S_ATTR_PURE_INSTRUCTIONS bit set. Therefore it doesn't think the next function symbol is function, so it keeps going. http://llvm.org/doxygen/MachOObjectFile_8cpp_source.html#l01945
Setting the bit indeed makes otool happy. |
Change https://golang.org/cl/105256 mentions this issue: |
What version of Go are you using (
go version
)?tip, also Go 1.10, 1.9, 1.8, 1.7
What operating system and processor architecture are you using (
go env
)?darwin/amd64 macOS 10.13.3
What did you do?
It appears that it doesn't know where a function ends. So it disassembles each function (mostly) to the end of TEXT. And again for the next function, disassemble to the end of TEXT, and again... This results in a giant disassembly output.
I remember I definitely did use otool to disassemble our binary before, and it worked. But it apparently doesn't work now for all recent versions of Go. Apparently otool is using LLVM-based objdump now. This is probably not the case before, when it worked for our binaries. I don't know when they switched. Maybe this is a bug in the LLVM-based objdump, I don't know. Or maybe there is something we can do to work around.
FWIW, lldb does disassemble our binary correctly.
The text was updated successfully, but these errors were encountered: