Re: [PATCH] gdb: handle DW_AT_entry_pc pointing at an empty sub-range

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 11/25/24 15:30, Andrew Burgess wrote:
> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> 
>> Okay, I just wanted to point out that in my opinion the debug info which
>> points at the end of a sub-range is not incorrect, just maybe on a border
>> line, where the dwarf spec is unclear.  So you should not say:
>> "after all, the DWARF spec is clear that such a range covers no code."
>>
>> But there are obviously not only cases where the entry_pc points at
>> an empty sub-range, but also in very rare cases the entry_pc points at
>> the end of a non-empty sub-range.
>> So could you please change the check in dwarf2_addr_in_block_ranges
>> from addr >= start && addr < end to addr >= start && addr <= end.
> 
> Could you expand on why you believe that the DWARF spec is unclear in
> this regard.  I came to my conclusion based on this text within the
> DWARF-5 specification, section 2.17.3 Non-Contiguous Address Ranges:
> 
>   Bounded range. This kind of entry defines an address range that is
>   included in the range list. The starting address is the lowest address
>   of the address range. The ending address is the address of the first
>   location past the highest address of the address range
> 
> This seems pretty clear (to me) that the end address is not part of the
> region covered by a range.
> 

Yes, but on the other hand, when we look at line table entries, each has a
PC and a VIEW number, and even the DW_AT_entry_pc has a DW_AT_GNU_entry_view,
just the range list does not have a view number, and that is inconsistent
with the concept of location views.

Consider as a simple example an inline function:

int f(int x)
{
 x++;
 return x;
}

it will most likely just be compiled into one "inc eax" or similar,
and of course you may want to set a break point on the return statement,
to inspect 'x' after the increment, but that will be on 'pc == end' !

But if the location view number would not be missing from the rnglist
it would be obvious whether the corresponding view number is still within
subroutine and not outside.  So in my opinion it is a defect in the
specification that it does not reflect this use case.


> Additionally, if we start to accept 'addr == end' then this is going to
> cause problems elsewhere.  GDB will place a b/p at the 'end' address,
> but when GDB then performs block lookup, GDB will not return the block
> we expect, and so GDB will not report the inferior as having stopped in
> the scope that the user expects.
> 

No, because this is exactly what the core of my patch does, admittedly
I also modified the block lookup code a bit, to handle that case.
So I strongly disagree here: we have to accept 'addr == end' and other
corner cases, otherwise my patch won't work in the end, regardless of in
how many small bug-fixes it can be split up, because it depends exactly
on not ignoring any information while parsing the debug info.


Thanks
Bernd,