Re: [PATCH] Fix dwarf-lineinfo inconsistency of inlined subroutines

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

On 11/19/19 3:01 AM, Alexandre Oliva wrote:
> Hello, Bernd,
> 
> Apologies for taking so long to respond.  I had not noticed your patch
> before being explicitly copied on it.
> 
> IIUC you're describing a problem in GDB, that could be summed up as its
> not paying attention to is_stmt and being unaware of location views, and
> you appear to be proposing to work around that by changing what AFAICT
> is a correct line number program into one that, though incorrect, will
> get more desirable behavior out of current GDB.
> 
> If that is so, I'm inclined to disagree that this is a desirable change.
> We should strive to generate correct, rather than incorrect debug
> information.  It was foreseen and expected that statement frontiers and
> location views would introduce occasional behavior regressions in
> debuggers unable to consume this information; what was not expected was
> that debuggers would lack support for it for so long.
> 
> I'd much rather make debug info incorrect, and instead introduce support
> for the extended debug info in consumers.  I realize it would take a lot
> more work to implement a proper fix there, however.  Unfortunately, I
> don't know of anyone currently working on that counterpart
> implementation, so the best recommendation I can offer to avoid this
> problem is to disable statement frontiers (-gno-statement-frontiers) and
> location views (-gno-variable-location-views).  This will get you line
> number programs and location lists that do not exercise features that
> GDB is not aware of.
> 
> Perhaps we should change our defaults, if the situation with GDB does
> not change :-(
> 

I tried those options, and -gno-variable-location-views changes
nothing in the debug exprience, but -gno-statement-frontiers
makes gdb do this:

Breakpoint 1, get_alias_set (t=t@entry=0x7ffff7ff6c60) at ../../gcc-10-20191117/gcc/alias.c:829
829     {
(gdb) n
837       if (t == error_mark_node
(gdb) n
829     {
(gdb) n
838           || (! TYPE_P (t)
(gdb) n
839               && (TREE_TYPE (t) == 0 || TREE_TYPE (t) == error_mark_node)))
(gdb) n
851           STRIP_NOPS (t);
(gdb)


So while the inline function is skipped this time, the function prologue
is executed twice, and the code is probably more jumpy than before.

It is interesting that my previous attempt at fixing it in gdb resulted
in basically the same effect :-/


My question to you is this: can you explain, given the following debug info, extracted
by readelf from alias.c, why the address 0x6e11 is in the inlined subroutine
and *not* in the get_alias_set function?  If you can explain it to me, I can probably
explain it to gdb as well.


  [0x00008b37]  Special opcode 61: advance Address by 4 to 0x6e04 and Line by 0 to 3386
  [0x00008b38]  Set is_stmt to 1
  [0x00008b39]  Special opcode 189: advance Address by 13 to 0x6e11 and Line by 2 to 3388
  [0x00008b3a]  Set is_stmt to 0
  [0x00008b3b]  Copy (view 1)
  [0x00008b3c]  Set File Name to entry 5 in the File Name Table
  [0x00008b3e]  Set column to 8
  [0x00008b40]  Advance Line by -2549 to 839

 <2><45b53>: Abbrev Number: 14 (DW_TAG_inlined_subroutine)
    <45b54>   DW_AT_abstract_origin: <0x4c5b0>
    <45b58>   DW_AT_entry_pc    : 0x6e00
    <45b60>   DW_AT_GNU_entry_view: 1
    <45b62>   DW_AT_ranges      : 0x9d60
    <45b66>   DW_AT_call_file   : 5
    <45b67>   DW_AT_call_line   : 839
    <45b69>   DW_AT_call_column : 8
    <45b6a>   DW_AT_sibling     : <0x45be4>

    00009d60 0000000000006e00 0000000000006e11
    00009d60 0000000000001115 000000000000112f
    00009d60 <End of list>

So I read this: when pc==0x6e11, the location is line 3388 (in tree.h) it is a statement.
But the inlined subroutine "contains_struct_check" extends from 0x6e00..0x6e11 and from
0x1115..0x112f.  Therefore 0x6e11 is OUTSIDE the subroutine, and that is what the gdb
thinks there as well.


Thanks
Bernd.