GDB does not show variables in inlined function

GDB does not show variables in inlined function

[Josef Zlomek]

Hello,

when using current GCC mainline and a function gets inlined
(by -funit-at-a-time)
GDB can't show variables of inlined function
(No symbol "incoming" in current context.)

The relevant part of debug info:

without inlining:

        .uleb128 0x25   # (DIE (0x458a) DW_TAG_variable)
        .long   .LASF986        # DW_AT_name: "incoming"
        .byte   0x1     # DW_AT_decl_file
        .value  0x3f32  # DW_AT_decl_line
        .long   0x2d    # DW_AT_type
        .byte   0x1     # DW_AT_location
        .byte   0x55    # DW_OP_reg5

with inlining:

        .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
        .long   0x2af2  # DW_AT_abstract_origin
                ^^^^^^
        .byte   0x1     # DW_AT_location
        .byte   0x56    # DW_OP_reg6
...
        .long   0x2d    # DW_AT_type
        .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
                                ^^^^^^
        .long   .LASF850        # DW_AT_name: "incoming"
        .byte   0x1     # DW_AT_decl_file
        .value  0x3f32  # DW_AT_decl_line
        .long   0x2d    # DW_AT_type

The location seems not to be generated for the real variable record
(2nd part after ...) with inlining.

Should GCC generate the location for the second part (after ...) too,
should GDB be able to link the descriptions through the marked number
or something else?

Thanks.

Josef

Re: GDB does not show variables in inlined function

[Daniel Jacobowitz]

On Tue, Jan 06, 2004 at 03:49:50PM +0100, Josef Zlomek wrote:
> with inlining:
> 
>         .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
>         .long   0x2af2  # DW_AT_abstract_origin
>                 ^^^^^^
>         .byte   0x1     # DW_AT_location
>         .byte   0x56    # DW_OP_reg6
> ...
>         .long   0x2d    # DW_AT_type
>         .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
>                                 ^^^^^^
>         .long   .LASF850        # DW_AT_name: "incoming"
>         .byte   0x1     # DW_AT_decl_file
>         .value  0x3f32  # DW_AT_decl_line
>         .long   0x2d    # DW_AT_type
> 
> The location seems not to be generated for the real variable record
> (2nd part after ...) with inlining.
> 
> Should GCC generate the location for the second part (after ...) too,
> should GDB be able to link the descriptions through the marked number
> or something else?

It's the former DIE (0x2a5a) which is in scope.  It has the name
"incoming" through the abstract origin chain.  So this is probably a
GDB issue.

Up until recently that DW_AT_location in the concrete DIE was missing,
I believe.  You might want to try this (incredibly lame, untested) GDB
patch.  Let me know if it does something useful.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.117
diff -u -p -r1.117 dwarf2read.c
--- dwarf2read.c	13 Dec 2003 22:29:06 -0000	1.117
+++ dwarf2read.c	6 Jan 2004 15:01:13 -0000
@@ -1813,7 +1813,6 @@ process_die (struct die_info *die, struc
       /* FIXME:  These are ignored for now.
          They could be used to set breakpoints on all inlined instances
          of a function and make GDB `next' properly over inlined functions.  */
-      break;
     case DW_TAG_lexical_block:
     case DW_TAG_try_block:
     case DW_TAG_catch_block:


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB does not show variables in inlined function

[Josef Zlomek]

> > with inlining:
> > 
> >         .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
> >         .long   0x2af2  # DW_AT_abstract_origin
> >                 ^^^^^^
> >         .byte   0x1     # DW_AT_location
> >         .byte   0x56    # DW_OP_reg6
> > ...
> >         .long   0x2d    # DW_AT_type
> >         .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
> >                                 ^^^^^^
> >         .long   .LASF850        # DW_AT_name: "incoming"
> >         .byte   0x1     # DW_AT_decl_file
> >         .value  0x3f32  # DW_AT_decl_line
> >         .long   0x2d    # DW_AT_type
> > 
> > The location seems not to be generated for the real variable record
> > (2nd part after ...) with inlining.
> > 
> > Should GCC generate the location for the second part (after ...) too,
> > should GDB be able to link the descriptions through the marked number
> > or something else?
> 
> It's the former DIE (0x2a5a) which is in scope.  It has the name
> "incoming" through the abstract origin chain.  So this is probably a
> GDB issue.
> 
> Up until recently that DW_AT_location in the concrete DIE was missing,
> I believe.  You might want to try this (incredibly lame, untested) GDB
> patch.  Let me know if it does something useful.

Wow, that was fast!
Yes, it works with your patch :-)

Josef

> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.117
> diff -u -p -r1.117 dwarf2read.c
> --- dwarf2read.c	13 Dec 2003 22:29:06 -0000	1.117
> +++ dwarf2read.c	6 Jan 2004 15:01:13 -0000
> @@ -1813,7 +1813,6 @@ process_die (struct die_info *die, struc
>        /* FIXME:  These are ignored for now.
>           They could be used to set breakpoints on all inlined instances
>           of a function and make GDB `next' properly over inlined functions.  */
> -      break;
>      case DW_TAG_lexical_block:
>      case DW_TAG_try_block:
>      case DW_TAG_catch_block:

Re: GDB does not show variables in inlined function

[Daniel Jacobowitz]

On Tue, Jan 06, 2004 at 04:27:19PM +0100, Josef Zlomek wrote:
> > > with inlining:
> > > 
> > >         .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
> > >         .long   0x2af2  # DW_AT_abstract_origin
> > >                 ^^^^^^
> > >         .byte   0x1     # DW_AT_location
> > >         .byte   0x56    # DW_OP_reg6
> > > ...
> > >         .long   0x2d    # DW_AT_type
> > >         .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
> > >                                 ^^^^^^
> > >         .long   .LASF850        # DW_AT_name: "incoming"
> > >         .byte   0x1     # DW_AT_decl_file
> > >         .value  0x3f32  # DW_AT_decl_line
> > >         .long   0x2d    # DW_AT_type
> > > 
> > > The location seems not to be generated for the real variable record
> > > (2nd part after ...) with inlining.
> > > 
> > > Should GCC generate the location for the second part (after ...) too,
> > > should GDB be able to link the descriptions through the marked number
> > > or something else?
> > 
> > It's the former DIE (0x2a5a) which is in scope.  It has the name
> > "incoming" through the abstract origin chain.  So this is probably a
> > GDB issue.
> > 
> > Up until recently that DW_AT_location in the concrete DIE was missing,
> > I believe.  You might want to try this (incredibly lame, untested) GDB
> > patch.  Let me know if it does something useful.
> 
> Wow, that was fast!
> Yes, it works with your patch :-)

Um... Josef, what GCC are you using?  I didn't check tree-ssa, but
neither 3.3 nor HEAD produces those DW_AT_location entries, which is a
serious (and filed in bugzilla, IIRC?) bug.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB does not show variables in inlined function

[Josef Zlomek]

> > > > with inlining:
> > > > 
> > > >         .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
> > > >         .long   0x2af2  # DW_AT_abstract_origin
> > > >                 ^^^^^^
> > > >         .byte   0x1     # DW_AT_location
> > > >         .byte   0x56    # DW_OP_reg6
> > > > ...
> > > >         .long   0x2d    # DW_AT_type
> > > >         .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
> > > >                                 ^^^^^^
> > > >         .long   .LASF850        # DW_AT_name: "incoming"
> > > >         .byte   0x1     # DW_AT_decl_file
> > > >         .value  0x3f32  # DW_AT_decl_line
> > > >         .long   0x2d    # DW_AT_type
> > > > 
> > > > The location seems not to be generated for the real variable record
> > > > (2nd part after ...) with inlining.
> > > > 
> > > > Should GCC generate the location for the second part (after ...) too,
> > > > should GDB be able to link the descriptions through the marked number
> > > > or something else?
> > > 
> > > It's the former DIE (0x2a5a) which is in scope.  It has the name
> > > "incoming" through the abstract origin chain.  So this is probably a
> > > GDB issue.
> > > 
> > > Up until recently that DW_AT_location in the concrete DIE was missing,
> > > I believe.  You might want to try this (incredibly lame, untested) GDB
> > > patch.  Let me know if it does something useful.
> > 
> > Wow, that was fast!
> > Yes, it works with your patch :-)
> 
> Um... Josef, what GCC are you using?  I didn't check tree-ssa, but
> neither 3.3 nor HEAD produces those DW_AT_location entries, which is a
> serious (and filed in bugzilla, IIRC?) bug.

I used HEAD (maybe few days old) and compiled var-tracking.c from hammer-3_3-branch.
I used "-g -O2 -dA" (-funit-at-a-time is default at -O2)

Josef

Re: GDB does not show variables in inlined function

[Daniel Jacobowitz]

On Tue, Jan 06, 2004 at 05:33:33PM +0100, Josef Zlomek wrote:
> > > > > with inlining:
> > > > > 
> > > > >         .uleb128 0x2c   # (DIE (0x2a5a) DW_TAG_variable)
> > > > >         .long   0x2af2  # DW_AT_abstract_origin
> > > > >                 ^^^^^^
> > > > >         .byte   0x1     # DW_AT_location
> > > > >         .byte   0x56    # DW_OP_reg6
> > > > > ...
> > > > >         .long   0x2d    # DW_AT_type
> > > > >         .uleb128 0x24   # (DIE (0x2af2) DW_TAG_variable)
> > > > >                                 ^^^^^^
> > > > >         .long   .LASF850        # DW_AT_name: "incoming"
> > > > >         .byte   0x1     # DW_AT_decl_file
> > > > >         .value  0x3f32  # DW_AT_decl_line
> > > > >         .long   0x2d    # DW_AT_type
> > > > > 
> > > > > The location seems not to be generated for the real variable record
> > > > > (2nd part after ...) with inlining.
> > > > > 
> > > > > Should GCC generate the location for the second part (after ...) too,
> > > > > should GDB be able to link the descriptions through the marked number
> > > > > or something else?
> > > > 
> > > > It's the former DIE (0x2a5a) which is in scope.  It has the name
> > > > "incoming" through the abstract origin chain.  So this is probably a
> > > > GDB issue.
> > > > 
> > > > Up until recently that DW_AT_location in the concrete DIE was missing,
> > > > I believe.  You might want to try this (incredibly lame, untested) GDB
> > > > patch.  Let me know if it does something useful.
> > > 
> > > Wow, that was fast!
> > > Yes, it works with your patch :-)
> > 
> > Um... Josef, what GCC are you using?  I didn't check tree-ssa, but
> > neither 3.3 nor HEAD produces those DW_AT_location entries, which is a
> > serious (and filed in bugzilla, IIRC?) bug.
> 
> I used HEAD (maybe few days old) and compiled var-tracking.c from hammer-3_3-branch.
> I used "-g -O2 -dA" (-funit-at-a-time is default at -O2)

It's really a shame that this feature was never reviewed for 3.4; it
would be extremely useful.  Let's make sure it goes in as soon as 3.4
has branched.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB does not show variables in inlined function

[Jim Blandy]

I like the patch.

Will the 'breako2' tests in gdb.base/break.exp exercise this?

Re: GDB does not show variables in inlined function

[Daniel Jacobowitz]

On Thu, Jan 08, 2004 at 07:06:58PM -0500, Jim Blandy wrote:
> 
> I like the patch.
> 
> Will the 'breako2' tests in gdb.base/break.exp exercise this?

No, I don't think so.  I've been sitting on it until I have time to
exercise it on both a compiler which produces inadequate debug info
(all current GCCs) and one which doesn't (like the hammer or rtlopt
branches, I think).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer