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

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 8 23:55:33 PDT 2019


avl marked an inline comment as done.
avl 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);
----------------
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. 


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

https://reviews.llvm.org/D59553





More information about the llvm-commits mailing list