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

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added a comment.

In D59553#1459554 <https://reviews.llvm.org/D59553#1459554>, @avl wrote:

> > I thought that address 0 is a good candidate to represent an invalid address, as nullptr is usually represented by address 0. I wonder why we want to use UINT64_MAX-2 instead of 0.
>
> using 0 in this case could lead to following problems :
>
> 1. on some platforms 0 is a valid address. i.e. image base starts from 0. In that case no way to differentiate valid address from invalid one just by checking for 0.


But this is also true to UINT64_MAX-2 because you can put your code or data there, no?

> 2. if size of deleted section is long enough then debug range could clash with valid section address range. That leads to incorrect debug info selecting. As written in another message :
> 
>> lld sets x86_64 image base to 0x200000.
>> A .debug_info associated with a non-discarded section has DW_AT_low_pc > 0x200000
>> A .debug_info associated with a discarded section has DW_AT_low_pc = 0. If its size is larger than 0x200000 => DW_AT_high_pc > image_base => the two debug info entries overlap => llvm->symbolizer locates a DIE that's not what the user expects => unexpected filename (not_used.cpp)
> 
> Using UINT64_MAX-1 prevents from above problems and allow to select correct DWARF entry.
> 
> in other words: using 0 as start of address range could lead to overlapping with valid address range.
>  using UINT64_MAX-1  as start of address range  makes address range of deleted section be outside of module address space and would not clash with existing ranges.




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

https://reviews.llvm.org/D59553