[PATCH] D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D59553#1571149 <https://reviews.llvm.org/D59553#1571149>, @MaskRay wrote:

> I disagree. For PIE output, 0 (__ehdr_start) points to the ELF header. It cannot be a valid code address. Note, the discussion is really about code addresses (DW_AT_low_pc, DW_AT_ranges, DW_AT_entry_pc, etc), not an unconstrained relocated file offset.


Not if the user is using linker scripts:

  /* test.script */
  PHDRS
  {
      ph_load PT_LOAD FLAGS(0x1|0x2|0x4);
  }
  
  SECTIONS
  {
      .text : {*(.text)} : ph_load
      .dynsym : { *(.dynsym) }
  }

bar.c:

  int bar(int x)
  {
      x += 10000;
      return x ? x/12345 : 10;
  }
  
  void _start()
  {
      bar(1234);
      bar(4321);
  }
  
  int foo(int x, int y)
  {
      x += 10000 + y;
      y += x - 123456;
  
      bar(1234);
      bar(4321);
  
  
      foo(1234, 4321);
      foo(4321, 1234);
  
      return y ? x/12345 : 10;
  }

Command-line:

  clang --target=x86_64-pc-linux bar.c -c -g -ffunction-sections
  ld.lld -pie bar.o -T test.script -o bar.elf --gc-sections

This results in the symbol bar being at address 0. The ELF header appears outside loadable memory. llvm-dwarfdump shows that 0 has been patched in the .debug_ranges field for both bar and foo. Running llvm-symbolizer and GNU addr2line produces mixed results:

  $ llvm-symbolizer 0 0x40 0x50 0x80 0x100 -e bar.elf
  bar
  C:\Work\TempWork\bar.c:2:0
  
  bar
  C:\Work\TempWork\bar.c:4:5
  
  _start
  C:\Work\TempWork\bar.c:8:0
  
  ??
  C:\Work\TempWork\bar.c:25:12
  
  ??
  ??:0:0
  
  $ addr2line 0 0x40 0x50 0x80 0x100 -e bar.elf -f
  bar
  C:\Work\TempWork/bar.c:14
  bar
  C:\Work\TempWork/bar.c:19
  _start
  C:\Work\TempWork/bar.c:22
  foo
  C:\Work\TempWork/bar.c:25
  ??
  ??:0

Issues I noticed, some of which are possibly bugs, but it's hard to tell:

- llvm-symbolizer reports the line number corresponding to the removed foo for the fourth case.
- GNU addr2line line numbers are wrong in the first three cases, and foo is reported in the fourth.
- GNU addr2line thinks foo is the right symbol for the fourth case, even though it has been removed. llvm-symbolizer just prints '??' (that's probably correct).

I haven't checked to see how many of these issues are fixed by D60470 <https://reviews.llvm.org/D60470>.


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

https://reviews.llvm.org/D59553