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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 6 00:26:42 PDT 2019


MaskRay added a comment.

I've some previous discussions PR37212 PR37891 etc. -2 or -1 may be benign to some non-allocated sections like .debug.*, but may not be good to others. The consumers may get used to treat 0 `DW_AT_low_pc` special but the patch may make some consumers code more special values. lld doesn't implement the `CB_PRETEND` logic in GNU linkers:

- gold CB_PRETEND https://sourceware.org/git/?p=binutils-gdb.git;a=blob;hb=9d6d4be89d12747a92629ed1bde1d423e2831de1;f=gold/target-reloc.h#l414
- ld.bfd action_discarded PRETEND https://sourceware.org/git/?p=binutils-gdb.git;a=blob;hb=9d6d4be89d12747a92629ed1bde1d423e2831de1;f=bfd/elflink.c#l10851

Maybe you can raise an issue on https://sourceware.org/bugzilla , asking if the relocation can be resolved to -2 if the PRETEND logic fails. I raised some issues in the weekend and the maintainers seem super responsible.

> But there are other platforms/compilation languages/linking options/linkers where this problem happens more often.

If you happen to know one combination, please elaborate :)

> I also do not think that zero DW_TAG_low_pc issue causes more problems to ld.bfd/gold linked modules than to lld linked modules.
> 
> The problem probably happened  less frequently for common x86 case when image-base starts from big values.

The image base doesn't matter (is zero) for -shared/-pie. I've shared my thoughts why this doesn't likely cause problems to lld. In lld, the PF_R PT_LOAD is placed before the PF_R|PF_X PT_LOAD (text segment). If you have a compilation unit that is sufficiently large (large `DW_AT_high_pc`, 0 `DW_AT_low_pc`), it is reasonable to have a sufficiently large PF_R PT_LOAD. Then the range will not collide with a good compilation unit with large `DW_AT_low_pc`.

On the GNU linkers' side, ld.bfd -z separate-code is a recent addition and it doesn't move the large .rodata etc before .text. gold hasn't implemented -z separate-code. They are more vulnerable to the issue.


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

https://reviews.llvm.org/D59553





More information about the llvm-commits mailing list