[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 inline comments.


================
Comment at: lld/ELF/InputSection.cpp:840
+      // UINT64_MAX has special usage in .debug_ranges.
+      // https://bugs.llvm.org/show_bug.cgi?id=41124
+      Target->relocateOne(BufLoc, Type, 0xfffffffffffffffeULL);
----------------
avl wrote:
> ruiu wrote:
> > avl wrote:
> > > ruiu wrote:
> > > > Where in this document can I find a description why UINT64_MAX is special? Is using UINT64_MAX-1 as an "invalid value" just a local convention of lld (i.e. are you inventing a new notion) or a common practice? Is there any more common value representing an invalid address than UINT64_MAX-1?
> > > It is based on the comment by @jhenderson  in start of this thread. He mentioned that -1 has issues in .debug_ranges. I would find the real description of using -1 for .debug_ranges and put here...
> > It's fine if -1 has a special meaning, but it doesn't necessarily mean -2 is the second best. For example, why don't you use 0? What's special about -2? Or is it just arbitrary?
> We need to prevent address clashing for debug info referenced to valid sections and to deleted sections. To achieve that it is necessary to set an address which is out of module scope. So the idea is to set maximal allowed address value. UINT64_MAX  is maximal value but used by .debug_aranges. UINT64_MAX -1 is the next maximal value. 
> 
> address range 0...0+LENGTH could clash with existing range.
> address range UINT64_MAX -1...UINT64_MAX -1+LENGTH is unlikely to be clashed. 
I think -1 also works, no need to use -2. -1 is used somewhere in `llvm/lib/DebugInfo/DWARF/` to indicate "the value is absent", exactly what we want to express here.


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

https://reviews.llvm.org/D59553