[PATCH] D59553: [WIP][LLD][ELF][DebugInfo] Use predefined value to mark debug address ranges pointing to deleted code.

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 8 14:25:15 PDT 2020


avl added a comment.



> Case 2 should not occur, I think; the compiler should not produce a range where low/high point to different sections.

It could occur when discarded section followed with the valid section. 
The range for discarded section is [LowPC,HighPC). HighPC points to the next byte after specified range. 
Thus HighPC could be valid address - LowPC of next range.

> Case 3 we are hoping will be detected and treated as an invalid range by consumers.

Probably, it makes sense to describe it directly in the DWARF standard? 
The same how it is already spoken for the zero-length ranges:

"A bounded range entry whose beginning and ending address offsets are equal
(including zero) indicates an empty range and may be ignored."

For LowPC>HighPC it could sound similarly:

"A bounded range entry whose beginning address offset greater than ending address offset
indicates an invalid range and may be ignored."

Thus, above situation would be explicitly described and then should be processed accordingly by consumers.

> There is an additional case to consider, which is this: Ranges can be specified (and in LLVM's case, now usually are) using a "base address" and then the low/high values are *both* offsets from that base address. We would want consumers to notice the base address was a special "invalid" or "points to nothing" value, and ignore any range that used low/high offsets from that base address.

yes. So we need more rules: Base address is being marked with -1/-2 according to last discussions. 
So DWARF standard should explicitly describe that all ranges using base address of -1/-2 value become invalid.
Right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59553





More information about the llvm-commits mailing list