[llvm-bugs] [Bug 45627] New: Ignore sections when printing branch targets in non-relocatable objects

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45627

            Bug ID: 45627
           Summary: Ignore sections when printing branch targets in
                    non-relocatable objects
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-objdump
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: llvm-bugs at lists.llvm.org

Currently, llvm-objdump tries to look up the symbols for call targets based on
the nearest section to a given address (i.e. the one with the highest address
that is not greater than the target address). If it can't find a symbol in the
given section with a value equal to or less than the target address, it falls
back to using absolute symbols.

This process has two problems. Firstly, if there happens to be an absolute
symbol with the correct value, but a symbol in the section picked also exists
with a lower address, the symbol in the section is picked instead, even though
there's an exact match. Secondly, if the target is the start address of a
section and there happens to be a symbol at the end of the preceding section,
with a matching symbol, it will never be picked, even if there are no symbols
in the section with the start address matching the target.

Both these behaviours are different to GNU objdump (in the version I tested at
least). Furthermore, I don't think the current behaviour even makes
philosophical sense - it shouldn't matter which section a symbol is in for it
to be considered a possible target. llvm-objdump should just pick the best one.
For example, a direct match will always be better than an indirect match, and
the section should only come into play when determining which of multiple
viable candidates should be picked.

Here is an example which illustrates both problems:

// bar.s
.text
    nop
.global end
end:

.section .text_1,"ax", at progbits
    nop
.global _start
_start:
    call _start - 1
    call _start + 1

.global abs
abs = 0x201123

// Commands
PS C:\Work\TempWork> C:\llvm\build\Debug\bin\clang.exe -c bar.s
PS C:\Work\TempWork> C:\llvm\build\Debug\bin\ld.lld.exe bar.o -o bar.elf
PS C:\Work\TempWork> C:\llvm\build\Debug\bin\llvm-objdump bar.elf -d

bar.elf:        file format elf64-x86-64


Disassembly of section .text:

0000000000201120 <.text>:
  201120: 90                            nop

Disassembly of section .text_1:

0000000000201121 <.text_1>:
  201121: 90                            nop

0000000000201122 <_start>:
  201122: e8 fa ff ff ff                callq   0x201121 <.text_1>
  201127: e8 f7 ff ff ff                callq   0x201123 <_start+0x1>
PS C:\Work\TempWork> objdump -d bar.elf

bar.elf:     file format elf64-x86-64


Disassembly of section .text:

0000000000201120 <end-0x1>:
  201120:       90                      nop

Disassembly of section .text_1:

0000000000201121 <_start-0x1>:
  201121:       90                      nop

0000000000201122 <_start>:
  201122:       e8 fa ff ff ff          callq  201121 <end>
  201127:       e8 f7 ff ff ff          callq  201123 <abs>

As can be seen, GNU objdump uses "end" and "abs" instead of the non-existent
.text_1 symbol and indirect _start+0x1 symbol. I think GNU's output here is
better than ours.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200421/e27f8d6e/attachment-0001.html>