[llvm-bugs] [Bug 47392] New: Do not warn for padding between functions without debug data when dumping with source/line info

[via llvm-bugs]

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

            Bug ID: 47392
           Summary: Do not warn for padding between functions without
                    debug data when dumping with source/line info
           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

llvm-objdump relatively recently started warning for objects without debug
data. See bug 41905 and commit 23c8a3ba6c7a913495cb85acfca27f0ed8b85182. An
unintended side-effect of this change is that it now starts warning if ANY byte
in the disassembly output has no corresponding source/line information. This
includes alignment padding added at link time between executable sections.

For example, the following source will result in a warning, when built with
-ffunction-sections and linked.

// bar.c
int func1() {
    return 42;
}

int _start() {
    return func1();
}

PS C:\Work\TempWork> C:\llvm\build\Debug\bin\clang.exe -c -g
-ffunction-sections bar.c
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.exe -d -S bar.elf

bar.elf:        file format elf64-x86-64


Disassembly of section .text:

0000000000201180 <func1>:
; int func1() {
  201180: 55                            pushq   %rbp
  201181: 48 89 e5                      movq    %rsp, %rbp
;     return 42;
  201184: b8 2a 00 00 00                movl    $42, %eax
  201189: 5d                            popq    %rbp
  20118a: c3                            retq
C:\llvm\build\Debug\bin\llvm-objdump.exe: warning: 'bar.elf': failed to parse
debug information for bar.elf
  20118b: cc                            int3
  20118c: cc                            int3
  20118d: cc                            int3
  20118e: cc                            int3
  20118f: cc                            int3

0000000000201190 <_start>:
; int _start() {
  201190: 55                            pushq   %rbp
  201191: 48 89 e5                      movq    %rsp, %rbp
;     return func1();
  201194: e8 e7 ff ff ff                callq   0x201180 <func1>
  201199: 5d                            popq    %rbp
  20119a: c3                            retq

The warning is misleading, in that it claims to have failed to parse the debug
information, but in fact, it successfully parsed the information, and simply
did not find any relevant information for some bits of the object. We should
not warn for padding clearly. It is harder to identify whether we should warn
for other functions, what to do if a specified range contains no debug data
(but other parts of the object do) and so on. We should probably also consider
improving the warning message to clearly indicate that no debug data was found
for the given address.

I have two possible suggestions:
1) If the area being disassembled is not covered by a symbol, do not warn. This
means that linker-added padding will not be warned for, but other executable
code which should be covered by symbols will be warned for.
2) Warn only if none of the code being disassembled has related debug data.
This means if dumping only a limited range covering only padding, a warning
will be produced, even if the object otherwise has valid debug data.

-- 
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/20200902/8abb66b6/attachment.html>