[PATCH] D74824: [objdump] Fix disassembly for call/branch instructions for ELF binaries built with -ffunction-sections

[Dave Bozier via Phabricator via llvm-commits]

davidb marked an inline comment as done.
davidb added inline comments.


================
Comment at: llvm/test/tools/llvm-objdump/X86/section-filter-relocs.test:13
 # DISASM-NEXT:  0000000000000400 .text:
-# DISASM-NEXT:  400: e8 00 00 00 00                callq   0 <.text+0x5>
+# DISASM-NEXT:  400: e8 00 00 00 00                callq   0 <foo>
 # RELOC-NEXT:                      00000401:  R_X86_64_PC32        foo+0x1
----------------
MaskRay wrote:
> `foo` is undefined. It is not correct to symbolize with an undefined symbol. The problem is that the display can get addends wrong.
> 
> For disassembly of object files, I think users should realize that they need to use `-d -r`.
>  It is not correct to symbolize with an undefined symbol.

What do you mean by `symbolize`? Are you saying it is incorrect to print the name of the symbol that the call or branch instruction is to be patched to when linked? How is <.text+0x5> more correct?that seems like garbage to me...

In the -ffunction-section case, these symbols are defined, but live in a separate section, and therefore require a relocation. The result is the same as if the symbol was undefined. Would it be ok if defined symbols were displayed, but undefined ones left to print garbage?

> For disassembly of object files, I think users should realize that they need to use -d -r.

This is pretty much what is being asked in the OP. And I'm not sure I agree. When a user is compiling ELF binaries with -ffunction-sections, then `-d` is pretty much useless. Worse than useless in the case that on some platforms it will pick the symbol name for that particular section, so it looks like a genuine call


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74824/new/

https://reviews.llvm.org/D74824