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

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

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

> @echristo @aprantl @probinson
>
> Folks, I would like to ask a question related to this review and DWARF standard:
>
> DWARF5 standard has the following statement related to non-continuous address ranges:
>
> > 2.17.3 Non-Contiguous Address Ranges
> >  ...
> >  A bounded range entry whose beginning and ending address offsets are equal
> >  (including zero) indicates an empty range and may be ignored.
>
> Would not it be useful to extend it to explicitly explain the following case
>  (for some next version of the standard)
>
> > "A bounded range entry whose beginning address offset greater than ending address offset
> >  indicates an invalid range and may be ignored. "
>
> ?
>
> This situation (LowPC > HighPC) already represents an invalid range.
>
> llvm-dwarfdump --verify :
>  error: Invalid address range [0xfffffffffffffffe, 0x0000000000000004)
>
> Thus it would be useful to indicate that explicitly and describe that default handling would be to skip.
>  So that broken ranges do not affect valid ranges.
>
> For this patch, it would mean that practically all cases 
>  would lead in this situation, and DWARF readers would adequately skip them :
>
> 1. ``` LowPC -> points to deleted section -> set to UINT64_MAX-1; HighPC -> points to deleted section -> set to UINT64_MAX-1;
>
>   ignored. ```
> 2.
>
>
>
>   LowPC -> points to deleted section -> set to UINT64_MAX-1; 
>   HighPC -> points to correct section -> set to some value less than UINT64_MAX-1;
>  
>   ignored.
>
>
>
>
> 3.
>
>
>
>   LowPC -> points to deleted section -> set to UINT64_MAX-1; 
>   Length has some value -> HighPC = UINT64_MAX-1 + value -> overflow -> less than LowPC
>  
>   ignored. 
>
>
> What do you think?


Answering this very old question:

Case 1 is a zero-length range and would always be interpreted that way.
Case 2 should not occur, I think; the compiler should not produce a range where low/high point to different sections.
Case 3 we are hoping will be detected and treated as an invalid range 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59553