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

[Andrew Burgess <aburgess@redhat.com>]

Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

> Hi Andrew,
>
> On 11/28/24 18:44, Andrew Burgess wrote:
>> Bernd,
>> 
>> Here's a v2 with an extended DWARF assembler test that now includes a
>> line table in some cases.  Specifically, when I test with label foo_6,
>> the address which is the end of a sub-range, which is also the end of
>> the entire block range, then I add a line table which indicates that
>> this address is the transition back from an inline function to the
>> outer function.
>> 
>
> Respect!
>
>
>> I've tested this with your series merge on top of this patch, and,
>> with your modified block lookup logic in place, and with the 'addr <
>> block->end ()' changed to 'addr <= block->end ()' in
>> dwarf2_addr_in_block_ranges (as well as in block::set_entry_pc) GDB is
>> able to stop at the foo_6 label.
>> 
>> I think you were OK with the v1 patch being merged, but I'll give you
>> some time to comment on the updated test.  If you're happy with this
>> then I'll get this merged.
>> 
>
> Yes, I am OK with the v1 patch to be merged now.

Great.  I pushed this patch.

>
>> Thanks,
>> Andrew
>> 
>
> P.S: As I was pretty busy the last days, I have not been able to
> give the requested data earlier, so here I have the line table of the
> step-and-next-inline-no-header, compiled with gcc-9.4.0:
>
> $ readelf -w step-and-next-inline-no-header
> [...]
>  <2><8d6>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
>     <8d7>   DW_AT_abstract_origin: <0x9c7>
>     <8db>   DW_AT_entry_pc    : 0x1189
>     <8e3>   DW_AT_GNU_entry_view: 0
>     <8e4>   DW_AT_ranges      : 0x30
> [...]
>     00000030 0000000000001189 0000000000001189 (start == end)
>     00000030 000000000000118d 0000000000001197
>     00000030 0000000000001060 0000000000001065
>     00000030 <End of list>
> [...]
>
> so the intersting end pc values are 0x1189 0x1197 and 0x1065.
>
> $ readelf -wL step-and-next-inline-no-header
> File name                        Line number    Starting address    View    Stmt
> [...]
> step-and-next-inline.cc                   54              0x1184       1
> step-and-next-inline.cc                   38              0x1189               x  -->+
> step-and-next-inline.cc                   40              0x1189       1       x     |
> step-and-next-inline.cc                   50              0x1189       2          <--+
> step-and-next-inline.cc                   40              0x118d        
> step-and-next-inline.cc                   40              0x118f        
> step-and-next-inline.cc                   42              0x1197               x  -->+
> step-and-next-inline.cc                   43              0x1197       1       x     |
> step-and-next-inline.cc                   43              0x1197       2             |
> step-and-next-inline.cc                   52              0x1197       3          <--+
> step-and-next-inline.cc                   52              0x119a        
> [...]
> step-and-next-inline.cc                   41              0x1060       1
> step-and-next-inline.cc                   41              0x1065        
> step-and-next-inline.cc                    -              0x1065        
>
> So we have most of the time one or two statement lines,
> followed by one or more non-statement lines at the end_pc, these
> statement lines are considered to be weak.  When we have a breakpoint
> there it should show the program stepping out of the inline to the
> calling function.
>
> Then we have the third line, which is a non-statement line followed
> by an end marker at the same pc, we usually ignore those, because they
> are unreachable, in this case after the abort(), and could easily be
> the beginning of the next function.  If we happen to have a breakpoint
> at this pc value, we should never consider any sub-range from the
> function before.  And a breakpoint there should show that we just
> entered the function.

Thanks for the details, and the analysis.

Thanks,
Andrew