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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

> 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>.

With D60470 <https://reviews.llvm.org/D60470>, you still see the following for the fourth case:

  ??
  C:\Work\TempWork\bar.c:25:12

It doesn't intend to fix this problem. What it tries to address, is if such discarded range overlaps with a valid normal range, the valid normal range will take priority. That change may also benefit ld.bfd and gold linked modules if their CB_PRETEND logic fails to apply. Because it also simplifies the code, I think it is still worth applying no matter the decision on this lld patch.

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

I agree in this case .text can have 0 link-time address.

I guess you probably don't need `.dynsym`. If this is a dynamically linked executable, it will have `.interp`, which is usually in the first page. Then `.text` will not have 0 `sh_addr`, and 0 will be an invalid code address. It is not common to have `.dynstr` after `.text` - it is before `.text` in BFD's default linker script.

For similar reasons, there should not be any .gnu.hash .dynstr `.rodata` `.eh_frame` etc. They are placed before `.text` by default in lld.

If you have `.note*` sections, you'll probably also place them in the first page. This ensures they are dumped by FreeBSD and Linux kernels when the core file size is limited.

In summary, to make 0 a valid code address in an lld linked module, lots of assumptions have to be made. These assumptions make the lld patch seem pretty much a hack for a very specialized use case.


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

https://reviews.llvm.org/D59553