Is this a gcc, gdb or readelf bug?

Is this a gcc, gdb or readelf bug?

[H. J. Lu]

I can't debug gcc 4.0 with gdb:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19124

When I used idb, I got

(idb) stop in tls_symbolic_operand

Info: Optimized variables show as <no value> when no location is
allocated.
[#1: stop in int tls_symbolic_operand(rtx, enum machine_mode)]
(idb) r

Is that a gdb/readelf or gcc bug?


H.J.

Re: Is this a gcc, gdb or readelf bug?

[Nick Clifton]

Hi H. J.

> I can't debug gcc 4.0 with gdb:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19124

Note - I have just committed a patch to readelf to make its output 
slightly more helpful when it encounters problems like this.

The 19124 bug is definitely a GCC problem - readelf is just reporting 
the facts, and as Andrew Pinkski has reported if you compile with 
-fno-var-tracking the problem goes away.

> When I used idb, I got
> 
> (idb) stop in tls_symbolic_operand
> 
> Info: Optimized variables show as <no value> when no location is
> allocated.
> [#1: stop in int tls_symbolic_operand(rtx, enum machine_mode)]
> (idb) r
> 
> Is that a gdb/readelf or gcc bug?

GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
problem of the compiler than was used to compile the GCC being 
debugged).  Either way I am pretty sure that readelf is blameless in 
this situation.

Cheers
   Nick

Re: Is this a gcc, gdb or readelf bug?

[H. J. Lu]

On Wed, Dec 22, 2004 at 11:16:13AM +0000, Nick Clifton wrote:
> Hi H. J.
> 
> >I can't debug gcc 4.0 with gdb:
> >
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19124
> 
> Note - I have just committed a patch to readelf to make its output 
> slightly more helpful when it encounters problems like this.

I believe there is a readelf bug:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=615

> 
> The 19124 bug is definitely a GCC problem - readelf is just reporting 
> the facts, and as Andrew Pinkski has reported if you compile with 
> -fno-var-tracking the problem goes away.
> 
> >When I used idb, I got
> >
> >(idb) stop in tls_symbolic_operand
> >
> >Info: Optimized variables show as <no value> when no location is
> >allocated.
> >[#1: stop in int tls_symbolic_operand(rtx, enum machine_mode)]
> >(idb) r
> >
> >Is that a gdb/readelf or gcc bug?
> 
> GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
> problem of the compiler than was used to compile the GCC being 
> debugged).  Either way I am pretty sure that readelf is blameless in 
> this situation.

I think gcc may be correct and gdb just can't handle location list
correctly.


H.J.

Re: Is this a gcc, gdb or readelf bug?

[Daniel Jacobowitz]

On Wed, Dec 22, 2004 at 10:24:49AM -0800, H. J. Lu wrote:
> > GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
> > problem of the compiler than was used to compile the GCC being 
> > debugged).  Either way I am pretty sure that readelf is blameless in 
> > this situation.
> 
> I think gcc may be correct and gdb just can't handle location list
> correctly.

If you believe there is a GDB bug, please submit a bug report with
self-contained test case.

-- 
Daniel Jacobowitz

GDB 6.3 assumes that DW_AT_frame_base exists

[H. J. Lu]

On Wed, Dec 22, 2004 at 10:43:19PM -0500, Daniel Jacobowitz wrote:
> On Wed, Dec 22, 2004 at 10:24:49AM -0800, H. J. Lu wrote:
> > > GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
> > > problem of the compiler than was used to compile the GCC being 
> > > debugged).  Either way I am pretty sure that readelf is blameless in 
> > > this situation.
> > 
> > I think gcc may be correct and gdb just can't handle location list
> > correctly.
> 
> If you believe there is a GDB bug, please submit a bug report with
> self-contained test case.

I don't know if it is a gcc or gdb bug, and I don't have a
self-contained testcase. The only thing I see is gdb crushes on
cc1 from gcc 4.0. It seems that gdb 6.3 assumes DW_AT_frame_base
exists for a function. But not all functions in cc1 in gcc 4.0
have DW_AT_frame_base and gdb 6.3 crushes in dwarf_expr_frame_base.

BTW, does gdb use bugzilla?

H.J.

Re: GDB 6.3 assumes that DW_AT_frame_base exists

[H. J. Lu]

On Thu, Dec 30, 2004 at 11:24:24AM -0800, H. J. Lu wrote:
> On Wed, Dec 22, 2004 at 10:43:19PM -0500, Daniel Jacobowitz wrote:
> > On Wed, Dec 22, 2004 at 10:24:49AM -0800, H. J. Lu wrote:
> > > > GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
> > > > problem of the compiler than was used to compile the GCC being 
> > > > debugged).  Either way I am pretty sure that readelf is blameless in 
> > > > this situation.
> > > 
> > > I think gcc may be correct and gdb just can't handle location list
> > > correctly.
> > 
> > If you believe there is a GDB bug, please submit a bug report with
> > self-contained test case.
> 
> I don't know if it is a gcc or gdb bug, and I don't have a
> self-contained testcase. The only thing I see is gdb crushes on
> cc1 from gcc 4.0. It seems that gdb 6.3 assumes DW_AT_frame_base
> exists for a function. But not all functions in cc1 in gcc 4.0
> have DW_AT_frame_base and gdb 6.3 crushes in dwarf_expr_frame_base.

I think it is a gdb 6.3 bug since idb has no problem. When evaluating
a location list, gdb does

	...
	ctx->get_frame_base = dwarf_expr_frame_base;
	...

dwarf_expr_frame_base uses DW_AT_frame_base to get frame base. Since
DW_AT_frame_base doesn't exist for tls_symbolic_operand, gdb crushes.


H.J.

Re: GDB 6.3 assumes that DW_AT_frame_base exists

[H. J. Lu]

On Thu, Dec 30, 2004 at 11:36:18AM -0800, H. J. Lu wrote:
> On Thu, Dec 30, 2004 at 11:24:24AM -0800, H. J. Lu wrote:
> > On Wed, Dec 22, 2004 at 10:43:19PM -0500, Daniel Jacobowitz wrote:
> > > On Wed, Dec 22, 2004 at 10:24:49AM -0800, H. J. Lu wrote:
> > > > > GDB not being able to debug GCC is a GDB problem.  (Or possibly a 
> > > > > problem of the compiler than was used to compile the GCC being 
> > > > > debugged).  Either way I am pretty sure that readelf is blameless in 
> > > > > this situation.
> > > > 
> > > > I think gcc may be correct and gdb just can't handle location list
> > > > correctly.
> > > 
> > > If you believe there is a GDB bug, please submit a bug report with
> > > self-contained test case.
> > 
> > I don't know if it is a gcc or gdb bug, and I don't have a
> > self-contained testcase. The only thing I see is gdb crushes on
> > cc1 from gcc 4.0. It seems that gdb 6.3 assumes DW_AT_frame_base
> > exists for a function. But not all functions in cc1 in gcc 4.0
> > have DW_AT_frame_base and gdb 6.3 crushes in dwarf_expr_frame_base.
> 
> I think it is a gdb 6.3 bug since idb has no problem. When evaluating
> a location list, gdb does
> 
> 	...
> 	ctx->get_frame_base = dwarf_expr_frame_base;
> 	...
> 
> dwarf_expr_frame_base uses DW_AT_frame_base to get frame base. Since
> DW_AT_frame_base doesn't exist for tls_symbolic_operand, gdb crushes.

DW_AT_frame_base may be needed for location lists of local variables.
But in case of tls_symbolic_operand, there is no local variable.
Location lists are used for function parameters.


H.J.

Re: GDB 6.3 assumes that DW_AT_frame_base exists

[Daniel Jacobowitz]

On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote:
> DW_AT_frame_base may be needed for location lists of local variables.
> But in case of tls_symbolic_operand, there is no local variable.
> Location lists are used for function parameters.

Then why is GDB calling get_frame_base?  It is only called for
DW_OP_fbreg.  If we don't have a frame base, we don't know what
DW_OP_fbreg refers to.

GDB should issue an error instead of crashing, but that's as far as we
can go.

-- 
Daniel Jacobowitz

Gdb generates location list without DW_AT_frame_base

[H. J. Lu]

On Thu, Dec 30, 2004 at 03:07:20PM -0500, Daniel Jacobowitz wrote:
> On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote:
> > DW_AT_frame_base may be needed for location lists of local variables.
> > But in case of tls_symbolic_operand, there is no local variable.
> > Location lists are used for function parameters.
> 
> Then why is GDB calling get_frame_base?  It is only called for
> DW_OP_fbreg.  If we don't have a frame base, we don't know what
> DW_OP_fbreg refers to.

Gcc generates:

 <1><28c955>: Abbrev Number: 47 (DW_TAG_subprogram)
     DW_AT_sibling     : <28c98f>
     DW_AT_external    : 1
     DW_AT_name        : (indirect string, offset: 0x3875d):
tls_symbolic_operand
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 471
     DW_AT_prototyped  : 1
     DW_AT_type        : <2887cb>
     DW_AT_low_pc      : 0x826c1d0
     DW_AT_high_pc     : 0x826c1fc
 <2><28c96f>: Abbrev Number: 48 (DW_TAG_formal_parameter)
     DW_AT_name        : op
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 470
     DW_AT_type        : <288a7b>
     DW_AT_location    : 120fbf (location list)
 <2><28c97e>: Abbrev Number: 49 (DW_TAG_formal_parameter)
     DW_AT_name        : (indirect string, offset: 0x3db66): mode
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 470
     DW_AT_type        : <288e5d>
     DW_AT_location    : 121018 (location list)

for

int
tls_symbolic_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
{
  return ((GET_CODE (op) == SYMBOL_REF) && (SYMBOL_REF_TLS_MODEL (op)
!= 0)) && (mode == VOIDmode || GET_MODE (op) == mode);
}

It may be a gcc bug after all.

> 
> GDB should issue an error instead of crashing, but that's as far as we
> can go.

This patch does something like that

--- dwarf2loc.c 2004-12-30 12:01:34.140350763 -0800
+++ dwarf2loc.c.new     2004-12-30 11:54:24.759408333 -0800
@@ -164,13 +164,16 @@ dwarf_expr_frame_base (void *baton, unsi
       *start = find_location_expression (symbaton, length,
                                         get_frame_pc
(debaton->frame));
     }
-  else
+  else if (SYMBOL_OPS (framefunc) == &dwarf2_locexpr_funcs)
     {
       struct dwarf2_locexpr_baton *symbaton;
       symbaton = SYMBOL_LOCATION_BATON (framefunc);
       *length = symbaton->size;
       *start = symbaton->data;
     }
+  else
+    error ("Invalid frame base function for \"%s\".",
+          SYMBOL_NATURAL_NAME (framefunc));

   if (*start == NULL)
     error ("Could not find the frame base for \"%s\".",


H.J.

Re: Gdb generates location list without DW_AT_frame_base

[Daniel Jacobowitz]

On Thu, Dec 30, 2004 at 12:23:46PM -0800, H. J. Lu wrote:
> On Thu, Dec 30, 2004 at 03:07:20PM -0500, Daniel Jacobowitz wrote:
> > On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote:
> > > DW_AT_frame_base may be needed for location lists of local variables.
> > > But in case of tls_symbolic_operand, there is no local variable.
> > > Location lists are used for function parameters.
> > 
> > Then why is GDB calling get_frame_base?  It is only called for
> > DW_OP_fbreg.  If we don't have a frame base, we don't know what
> > DW_OP_fbreg refers to.
> 
> Gcc generates:
> 
>  <1><28c955>: Abbrev Number: 47 (DW_TAG_subprogram)
>      DW_AT_sibling     : <28c98f>
>      DW_AT_external    : 1
>      DW_AT_name        : (indirect string, offset: 0x3875d):
> tls_symbolic_operand
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 471
>      DW_AT_prototyped  : 1
>      DW_AT_type        : <2887cb>
>      DW_AT_low_pc      : 0x826c1d0
>      DW_AT_high_pc     : 0x826c1fc
>  <2><28c96f>: Abbrev Number: 48 (DW_TAG_formal_parameter)
>      DW_AT_name        : op
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 470
>      DW_AT_type        : <288a7b>
>      DW_AT_location    : 120fbf (location list)
>  <2><28c97e>: Abbrev Number: 49 (DW_TAG_formal_parameter)
>      DW_AT_name        : (indirect string, offset: 0x3db66): mode
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 470
>      DW_AT_type        : <288e5d>
>      DW_AT_location    : 121018 (location list)
> 
> for
> 
> int
> tls_symbolic_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
> {
>   return ((GET_CODE (op) == SYMBOL_REF) && (SYMBOL_REF_TLS_MODEL (op)
> != 0)) && (mode == VOIDmode || GET_MODE (op) == mode);
> }
> 
> It may be a gcc bug after all.

And what's in the location lists?  If it's DW_OP_fbreg, then I presume
it's a GCC bug.  According to my reading of the DWARF spec, anyway.

-- 
Daniel Jacobowitz

Gdb generates DW_OP_fbreg in location list without DW_AT_frame_base

[H. J. Lu]

On Thu, Dec 30, 2004 at 03:28:28PM -0500, Daniel Jacobowitz wrote:
> On Thu, Dec 30, 2004 at 12:23:46PM -0800, H. J. Lu wrote:
> > On Thu, Dec 30, 2004 at 03:07:20PM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote:
> > > > DW_AT_frame_base may be needed for location lists of local variables.
> > > > But in case of tls_symbolic_operand, there is no local variable.
> > > > Location lists are used for function parameters.
> > > 
> > > Then why is GDB calling get_frame_base?  It is only called for
> > > DW_OP_fbreg.  If we don't have a frame base, we don't know what
> > > DW_OP_fbreg refers to.
> > 
> > Gcc generates:
> > 
> >  <1><28c955>: Abbrev Number: 47 (DW_TAG_subprogram)
> >      DW_AT_sibling     : <28c98f>
> >      DW_AT_external    : 1
> >      DW_AT_name        : (indirect string, offset: 0x3875d):
> > tls_symbolic_operand
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 471
> >      DW_AT_prototyped  : 1
> >      DW_AT_type        : <2887cb>
> >      DW_AT_low_pc      : 0x826c1d0
> >      DW_AT_high_pc     : 0x826c1fc
> >  <2><28c96f>: Abbrev Number: 48 (DW_TAG_formal_parameter)
> >      DW_AT_name        : op
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 470
> >      DW_AT_type        : <288a7b>
> >      DW_AT_location    : 120fbf (location list)
> >  <2><28c97e>: Abbrev Number: 49 (DW_TAG_formal_parameter)
> >      DW_AT_name        : (indirect string, offset: 0x3db66): mode
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 470
> >      DW_AT_type        : <288e5d>
> >      DW_AT_location    : 121018 (location list)
> > 
> > for
> > 
> > int
> > tls_symbolic_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
> > {
> >   return ((GET_CODE (op) == SYMBOL_REF) && (SYMBOL_REF_TLS_MODEL (op)
> > != 0)) && (mode == VOIDmode || GET_MODE (op) == mode);
> > }
> > 
> > It may be a gcc bug after all.
> 
> And what's in the location lists?  If it's DW_OP_fbreg, then I presume
> it's a GCC bug.  According to my reading of the DWARF spec, anyway.
> 

 <1><418c>: Abbrev Number: 47 (DW_TAG_subprogram)
     DW_AT_sibling     : <41c6>	
     DW_AT_external    : 1	
     DW_AT_name        : (indirect string, offset: 0x3133): tls_symbolic_operand	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 471	
     DW_AT_prototyped  : 1	
     DW_AT_type        : <2c>	
     DW_AT_low_pc      : 0x2f0	
     DW_AT_high_pc     : 0x31c	
 <2><41a6>: Abbrev Number: 48 (DW_TAG_formal_parameter)
     DW_AT_name        : op	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 470	
     DW_AT_type        : <2dc>	
     DW_AT_location    : 549	(location list)
 <2><41b5>: Abbrev Number: 49 (DW_TAG_formal_parameter)
     DW_AT_name        : (indirect string, offset: 0x44e5): mode	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 470	
     DW_AT_type        : <6be>	
     DW_AT_location    : 5a2	(location list)

    00000549 000002f0 000002fe (DW_OP_fbreg: 4)
    00000549 000002fe 00000300 (DW_OP_reg0)
    00000549 00000300 00000301 (DW_OP_fbreg: 4)
    00000549 00000301 0000030b (DW_OP_reg0)
    00000549 0000030b 00000311 (DW_OP_fbreg: 4)
    00000549 00000311 00000315 (DW_OP_reg0)
    00000549 00000315 0000031c (DW_OP_fbreg: 4)

    000005a2 000002f0 000002fe (DW_OP_fbreg: 8)
    000005a2 000002fe 0000031c (DW_OP_reg2)

Re: Gdb generates location list without DW_AT_frame_base

[Daniel Berlin]

> And what's in the location lists?  If it's DW_OP_fbreg, then I presume
> it's a GCC bug.  According to my reading of the DWARF spec, anyway.
It is.

I added code to tell it when not to use fbreg, but i only told it not to
use fbreg in the location expression when we were outputting the
frame_base attribute.

However, it appears we don't output a frame base attribute for external
procedures, so we need to tell it it can't use if we don't have a frame
base attribute.

You just need to change when loc_descriptor is called with a second
parameter of true/1 to fix this.

--Dan

Re: Gdb generates location list without DW_AT_frame_base

[H. J. Lu]

On Thu, Dec 30, 2004 at 03:56:33PM -0500, Daniel Berlin wrote:
> 
> > And what's in the location lists?  If it's DW_OP_fbreg, then I presume
> > it's a GCC bug.  According to my reading of the DWARF spec, anyway.
> It is.
> 
> I added code to tell it when not to use fbreg, but i only told it not to
> use fbreg in the location expression when we were outputting the
> frame_base attribute.
> 
> However, it appears we don't output a frame base attribute for external
> procedures, so we need to tell it it can't use if we don't have a frame
> base attribute.
> 
> You just need to change when loc_descriptor is called with a second
> parameter of true/1 to fix this.

Do you have a patch I can try?


H.J.

Re: Gdb generates location list without DW_AT_frame_base

[Daniel Berlin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 804 bytes --]



On Thu, 30 Dec 2004, H. J. Lu wrote:

> On Thu, Dec 30, 2004 at 03:56:33PM -0500, Daniel Berlin wrote:
>>
>>> And what's in the location lists?  If it's DW_OP_fbreg, then I presume
>>> it's a GCC bug.  According to my reading of the DWARF spec, anyway.
>> It is.
>>
>> I added code to tell it when not to use fbreg, but i only told it not to
>> use fbreg in the location expression when we were outputting the
>> frame_base attribute.
>>
>> However, it appears we don't output a frame base attribute for external
>> procedures, so we need to tell it it can't use if we don't have a frame
>> base attribute.
>>
>> You just need to change when loc_descriptor is called with a second
>> parameter of true/1 to fix this.
>
> Do you have a patch I can try?

This may not fix all of them, but it should help.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1148 bytes --]

Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.564
diff -u -p -r1.564 dwarf2out.c
--- dwarf2out.c	24 Dec 2004 05:23:07 -0000	1.564
+++ dwarf2out.c	31 Dec 2004 00:34:38 -0000
@@ -9980,6 +9980,7 @@ add_location_or_const_value_attribute (d
   rtx rtl;
   dw_loc_descr_ref descr;
   var_loc_list *loc_list;
+  bool can_use_fb = attr != DW_AT_frame_base && !DECL_EXTERNAL (decl);
 
   if (TREE_CODE (decl) == ERROR_MARK)
     return;
@@ -10049,7 +10050,7 @@ add_location_or_const_value_attribute (d
 	    varloc = NOTE_VAR_LOCATION (node->var_loc_note);
 	    add_loc_descr_to_loc_list (&list,
 				       loc_descriptor (varloc,
-						       attr != DW_AT_frame_base),
+						       can_use_fb),
 				       node->label, node->next->label, secname);
 	  }
 
@@ -10070,7 +10071,7 @@ add_location_or_const_value_attribute (d
 	    }
 	  add_loc_descr_to_loc_list (&list,
 				     loc_descriptor (varloc,
-						     attr != DW_AT_frame_base),
+						     can_use_fb),
 				     node->label, endname, secname);
 	}
 

Re: Gdb generates location list without DW_AT_frame_base

[H. J. Lu]

On Thu, Dec 30, 2004 at 07:35:13PM -0500, Daniel Berlin wrote:
> 
> 
> On Thu, 30 Dec 2004, H. J. Lu wrote:
> 
> >On Thu, Dec 30, 2004 at 03:56:33PM -0500, Daniel Berlin wrote:
> >>
> >>>And what's in the location lists?  If it's DW_OP_fbreg, then I presume
> >>>it's a GCC bug.  According to my reading of the DWARF spec, anyway.
> >>It is.
> >>
> >>I added code to tell it when not to use fbreg, but i only told it not to
> >>use fbreg in the location expression when we were outputting the
> >>frame_base attribute.
> >>
> >>However, it appears we don't output a frame base attribute for external
> >>procedures, so we need to tell it it can't use if we don't have a frame
> >>base attribute.
> >>
> >>You just need to change when loc_descriptor is called with a second
> >>parameter of true/1 to fix this.
> >
> >Do you have a patch I can try?
> 
> This may not fix all of them, but it should help.

> Index: dwarf2out.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
> retrieving revision 1.564
> diff -u -p -r1.564 dwarf2out.c
> --- dwarf2out.c	24 Dec 2004 05:23:07 -0000	1.564
> +++ dwarf2out.c	31 Dec 2004 00:34:38 -0000
> @@ -9980,6 +9980,7 @@ add_location_or_const_value_attribute (d
>    rtx rtl;
>    dw_loc_descr_ref descr;
>    var_loc_list *loc_list;
> +  bool can_use_fb = attr != DW_AT_frame_base && !DECL_EXTERNAL (decl);
>  
>    if (TREE_CODE (decl) == ERROR_MARK)
>      return;
> @@ -10049,7 +10050,7 @@ add_location_or_const_value_attribute (d
>  	    varloc = NOTE_VAR_LOCATION (node->var_loc_note);
>  	    add_loc_descr_to_loc_list (&list,
>  				       loc_descriptor (varloc,
> -						       attr != DW_AT_frame_base),
> +						       can_use_fb),
>  				       node->label, node->next->label, secname);
>  	  }
>  
> @@ -10070,7 +10071,7 @@ add_location_or_const_value_attribute (d
>  	    }
>  	  add_loc_descr_to_loc_list (&list,
>  				     loc_descriptor (varloc,
> -						     attr != DW_AT_frame_base),
> +						     can_use_fb),
>  				     node->label, endname, secname);
>  	}
>  

There are several problems with this patch:

1. It checks DECL_EXTERNAL. Did you mean TREE_PUBLIC?
2. It doesn't cover PARM_DECL nor RESULT_DECL.
3. For

#0  loc_descriptor (rtl=0xb7d67abc, can_use_fbreg=1 '\001')
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:8740
#1  0x0813bd45 in loc_descriptor_from_tree_1 (loc=0xb7d60870,
want_address=2)
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:8928
#2  0x0813c2b7 in add_location_or_const_value_attribute
(die=0xb7d66f3c,
    decl=0xb7d60870, attr=DW_AT_location)
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:9247
#3  0x08141ec6 in gen_formal_parameter_die (node=0xb7d60870,
    context_die=0xb7d66ea0)
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:11001
#4  0x0813ded2 in gen_decl_die (decl=0xb7d60870,
context_die=0xb7d66ea0)
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:12700
#5  0x08140479 in gen_subprogram_die (decl=0xb7d601b0,
context_die=0x84da799)
    at /net/gnu/export/gnu/src/gcc/gcc/gcc/dwarf2out.c:11382

it comes from

   8926             /* Certain constructs can only be represented at
top-level.  */
   8927             if (want_address == 2)
   8928               return loc_descriptor (rtl, true);
   8929

H.J.

Re: Gdb generates location list without DW_AT_frame_base

[Daniel Berlin]

>
> There are several problems with this patch:
>
> 1. It checks DECL_EXTERNAL. Did you mean TREE_PUBLIC?

No.
Look at the conditions for generating a frame_base.

I'll fix the other cases.

Re: Gdb generates location list without DW_AT_frame_base

[H. J. Lu]

On Fri, Dec 31, 2004 at 11:57:34AM -0800, H. J. Lu wrote:
> On Thu, Dec 30, 2004 at 07:35:13PM -0500, Daniel Berlin wrote:
> > 
> > 
> > On Thu, 30 Dec 2004, H. J. Lu wrote:
> > 
> > >On Thu, Dec 30, 2004 at 03:56:33PM -0500, Daniel Berlin wrote:
> > >>
> > >>>And what's in the location lists?  If it's DW_OP_fbreg, then I presume
> > >>>it's a GCC bug.  According to my reading of the DWARF spec, anyway.
> > >>It is.
> > >>
> > >>I added code to tell it when not to use fbreg, but i only told it not to
> > >>use fbreg in the location expression when we were outputting the
> > >>frame_base attribute.
> > >>
> > >>However, it appears we don't output a frame base attribute for external
> > >>procedures, so we need to tell it it can't use if we don't have a frame
> > >>base attribute.
> > >>
> > >>You just need to change when loc_descriptor is called with a second
> > >>parameter of true/1 to fix this.
> > >
> > >Do you have a patch I can try?
> > 
> > This may not fix all of them, but it should help.
> 
> > Index: dwarf2out.c
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
> > retrieving revision 1.564
> > diff -u -p -r1.564 dwarf2out.c
> > --- dwarf2out.c	24 Dec 2004 05:23:07 -0000	1.564
> > +++ dwarf2out.c	31 Dec 2004 00:34:38 -0000
> > @@ -9980,6 +9980,7 @@ add_location_or_const_value_attribute (d
> >    rtx rtl;
> >    dw_loc_descr_ref descr;
> >    var_loc_list *loc_list;
> > +  bool can_use_fb = attr != DW_AT_frame_base && !DECL_EXTERNAL (decl);
> >  
> >    if (TREE_CODE (decl) == ERROR_MARK)
> >      return;
> > @@ -10049,7 +10050,7 @@ add_location_or_const_value_attribute (d
> >  	    varloc = NOTE_VAR_LOCATION (node->var_loc_note);
> >  	    add_loc_descr_to_loc_list (&list,
> >  				       loc_descriptor (varloc,
> > -						       attr != DW_AT_frame_base),
> > +						       can_use_fb),
> >  				       node->label, node->next->label, secname);
> >  	  }
> >  
> > @@ -10070,7 +10071,7 @@ add_location_or_const_value_attribute (d
> >  	    }
> >  	  add_loc_descr_to_loc_list (&list,
> >  				     loc_descriptor (varloc,
> > -						     attr != DW_AT_frame_base),
> > +						     can_use_fb),
> >  				     node->label, endname, secname);
> >  	}
> >  
> 
> There are several problems with this patch:
> 
> 1. It checks DECL_EXTERNAL. Did you mean TREE_PUBLIC?
> 2. It doesn't cover PARM_DECL nor RESULT_DECL.
> 3. For
> 

This patch seems to generate better debug info.


H.J.
--- dwarf2out.c.loc	2004-12-27 12:04:10.000000000 -0800
+++ dwarf2out.c	2004-12-31 12:10:01.400120743 -0800
@@ -3919,8 +3919,8 @@ static int is_based_loc (rtx);
 static dw_loc_descr_ref mem_loc_descriptor (rtx, enum machine_mode mode, bool);
 static dw_loc_descr_ref concat_loc_descriptor (rtx, rtx);
 static dw_loc_descr_ref loc_descriptor (rtx, bool);
-static dw_loc_descr_ref loc_descriptor_from_tree_1 (tree, int);
-static dw_loc_descr_ref loc_descriptor_from_tree (tree);
+static dw_loc_descr_ref loc_descriptor_from_tree_1 (tree, bool, int);
+static dw_loc_descr_ref loc_descriptor_from_tree (tree, bool);
 static HOST_WIDE_INT ceiling (HOST_WIDE_INT, unsigned int);
 static tree field_type (tree);
 static unsigned int simple_type_align_in_bits (tree);
@@ -8815,7 +8815,7 @@ loc_descriptor (rtx rtl, bool can_use_fb
    the value of LOC.  */
 
 static dw_loc_descr_ref
-loc_descriptor_from_tree_1 (tree loc, int want_address)
+loc_descriptor_from_tree_1 (tree loc, bool can_use_fb, int want_address)
 {
   dw_loc_descr_ref ret, ret1;
   int have_address = 0;
@@ -8854,7 +8854,7 @@ loc_descriptor_from_tree_1 (tree loc, in
 	return 0;
 
       /* Otherwise, process the argument and look for the address.  */
-      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 1);
+      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 1);
 
     case VAR_DECL:
       if (DECL_THREAD_LOCAL (loc))
@@ -8895,7 +8895,8 @@ loc_descriptor_from_tree_1 (tree loc, in
 
     case PARM_DECL:
       if (DECL_VALUE_EXPR (loc))
-	return loc_descriptor_from_tree_1 (DECL_VALUE_EXPR (loc), want_address);
+	return loc_descriptor_from_tree_1 (DECL_VALUE_EXPR (loc), can_use_fb,
+					   want_address);
       /* FALLTHRU */
 
     case RESULT_DECL:
@@ -8925,7 +8926,7 @@ loc_descriptor_from_tree_1 (tree loc, in
 
 	    /* Certain constructs can only be represented at top-level.  */
 	    if (want_address == 2)
-	      return loc_descriptor (rtl, true);
+	      return loc_descriptor (rtl, can_use_fb);
 
 	    mode = GET_MODE (rtl);
 	    if (MEM_P (rtl))
@@ -8933,18 +8934,19 @@ loc_descriptor_from_tree_1 (tree loc, in
 		rtl = XEXP (rtl, 0);
 		have_address = 1;
 	      }
-	    ret = mem_loc_descriptor (rtl, mode, true);
+	    ret = mem_loc_descriptor (rtl, mode, can_use_fb);
 	  }
       }
       break;
 
     case INDIRECT_REF:
-      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 0);
+      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 0);
       have_address = 1;
       break;
 
     case COMPOUND_EXPR:
-      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), want_address);
+      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), can_use_fb,
+					 want_address);
 
     case NOP_EXPR:
     case CONVERT_EXPR:
@@ -8952,7 +8954,8 @@ loc_descriptor_from_tree_1 (tree loc, in
     case VIEW_CONVERT_EXPR:
     case SAVE_EXPR:
     case MODIFY_EXPR:
-      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), want_address);
+      return loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb,
+					 want_address);
 
     case COMPONENT_REF:
     case BIT_FIELD_REF:
@@ -8970,7 +8973,7 @@ loc_descriptor_from_tree_1 (tree loc, in
 	if (obj == loc)
 	  return 0;
 
-	ret = loc_descriptor_from_tree_1 (obj, 1);
+	ret = loc_descriptor_from_tree_1 (obj, can_use_fb, 1);
 	if (ret == 0
 	    || bitpos % BITS_PER_UNIT != 0 || bitsize % BITS_PER_UNIT != 0)
 	  return 0;
@@ -8978,7 +8981,8 @@ loc_descriptor_from_tree_1 (tree loc, in
 	if (offset != NULL_TREE)
 	  {
 	    /* Variable offset.  */
-	    add_loc_descr (&ret, loc_descriptor_from_tree_1 (offset, 0));
+	    add_loc_descr (&ret, loc_descriptor_from_tree_1 (offset, can_use_fb,
+							     0));
 	    add_loc_descr (&ret, new_loc_descr (DW_OP_plus, 0, 0));
 	  }
 
@@ -9012,7 +9016,7 @@ loc_descriptor_from_tree_1 (tree loc, in
 	  return 0;
 	mode = GET_MODE (rtl);
 	rtl = XEXP (rtl, 0);
-	ret = mem_loc_descriptor (rtl, mode, true);
+	ret = mem_loc_descriptor (rtl, mode, can_use_fb);
 	have_address = 1;
 	break;
       }
@@ -9068,7 +9072,7 @@ loc_descriptor_from_tree_1 (tree loc, in
       if (TREE_CODE (TREE_OPERAND (loc, 1)) == INTEGER_CST
 	  && host_integerp (TREE_OPERAND (loc, 1), 0))
 	{
-	  ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 0);
+	  ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 0);
 	  if (ret == 0)
 	    return 0;
 
@@ -9120,8 +9124,8 @@ loc_descriptor_from_tree_1 (tree loc, in
       goto do_binop;
 
     do_binop:
-      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 0);
-      ret1 = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), 0);
+      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 0);
+      ret1 = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), can_use_fb, 0);
       if (ret == 0 || ret1 == 0)
 	return 0;
 
@@ -9143,7 +9147,7 @@ loc_descriptor_from_tree_1 (tree loc, in
       goto do_unop;
 
     do_unop:
-      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 0);
+      ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 0);
       if (ret == 0)
 	return 0;
 
@@ -9167,12 +9171,12 @@ loc_descriptor_from_tree_1 (tree loc, in
     case COND_EXPR:
       {
 	dw_loc_descr_ref lhs
-	  = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), 0);
+	  = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 1), can_use_fb, 0);
 	dw_loc_descr_ref rhs
-	  = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 2), 0);
+	  = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 2), can_use_fb, 0);
 	dw_loc_descr_ref bra_node, jump_node, tmp;
 
-	ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), 0);
+	ret = loc_descriptor_from_tree_1 (TREE_OPERAND (loc, 0), can_use_fb, 0);
 	if (ret == 0 || lhs == 0 || rhs == 0)
 	  return 0;
 
@@ -9242,9 +9246,9 @@ loc_descriptor_from_tree_1 (tree loc, in
 }
 
 static inline dw_loc_descr_ref
-loc_descriptor_from_tree (tree loc)
+loc_descriptor_from_tree (tree loc, bool can_use_fb)
 {
-  return loc_descriptor_from_tree_1 (loc, 2);
+  return loc_descriptor_from_tree_1 (loc, can_use_fb, 2);
 }
 
 /* Given a value, round it up to the lowest multiple of `boundary'
@@ -9980,6 +9984,7 @@ add_location_or_const_value_attribute (d
   rtx rtl;
   dw_loc_descr_ref descr;
   var_loc_list *loc_list;
+  bool can_use_fb;
 
   if (TREE_CODE (decl) == ERROR_MARK)
     return;
@@ -9987,6 +9992,17 @@ add_location_or_const_value_attribute (d
   gcc_assert (TREE_CODE (decl) == VAR_DECL || TREE_CODE (decl) == PARM_DECL
 	      || TREE_CODE (decl) == RESULT_DECL);
 
+  switch (TREE_CODE (decl))
+    {
+    default:
+      can_use_fb = attr != DW_AT_frame_base && !TREE_PUBLIC (decl);
+      break;
+     case PARM_DECL:
+     case RESULT_DECL:
+      can_use_fb = attr != DW_AT_frame_base && !TREE_PUBLIC (DECL_CONTEXT (decl));
+      break;
+    }
+
   /* See if we possibly have multiple locations for this variable.  */
   loc_list = lookup_decl_loc (decl);
 
@@ -10037,7 +10053,7 @@ add_location_or_const_value_attribute (d
 
       node = loc_list->first;
       varloc = NOTE_VAR_LOCATION (node->var_loc_note);
-      list = new_loc_list (loc_descriptor (varloc, attr != DW_AT_frame_base),
+      list = new_loc_list (loc_descriptor (varloc, can_use_fb),
 			   node->label, node->next->label, secname, 1);
       node = node->next;
 
@@ -10049,7 +10065,7 @@ add_location_or_const_value_attribute (d
 	    varloc = NOTE_VAR_LOCATION (node->var_loc_note);
 	    add_loc_descr_to_loc_list (&list,
 				       loc_descriptor (varloc,
-						       attr != DW_AT_frame_base),
+						       can_use_fb),
 				       node->label, node->next->label, secname);
 	  }
 
@@ -10070,7 +10086,7 @@ add_location_or_const_value_attribute (d
 	    }
 	  add_loc_descr_to_loc_list (&list,
 				     loc_descriptor (varloc,
-						     attr != DW_AT_frame_base),
+						     can_use_fb),
 				     node->label, endname, secname);
 	}
 
@@ -10086,7 +10102,7 @@ add_location_or_const_value_attribute (d
       return;
     }
 
-  descr = loc_descriptor_from_tree (decl);
+  descr = loc_descriptor_from_tree (decl, can_use_fb);
   if (descr)
     add_AT_location_description (die, attr, descr);
 }
@@ -10205,7 +10221,7 @@ add_bound_info (dw_die_ref subrange_die,
 	dw_die_ref ctx, decl_die;
 	dw_loc_descr_ref loc;
 
-	loc = loc_descriptor_from_tree (bound);
+	loc = loc_descriptor_from_tree (bound, false);
 	if (loc == NULL)
 	  break;
 
@@ -11331,7 +11347,7 @@ gen_subprogram_die (tree decl, dw_die_re
 
       if (cfun->static_chain_decl)
 	add_AT_location_description (subr_die, DW_AT_static_link,
-		 loc_descriptor_from_tree (cfun->static_chain_decl));
+		 loc_descriptor_from_tree (cfun->static_chain_decl, false));
     }
 
   /* Now output descriptions of the arguments for this function. This gets

Re: Gdb generates location list without DW_AT_frame_base

[Daniel Berlin]

>
> This patch seems to generate better debug info.

You missed a whole bunch of cases where we are arbitrarily passing true to 
mem_loc_descriptor or loc_descriptor.
You also *can* generate a frame base for the testcase you sent me, we just 
don't use all the info we could to generate it.
See the last patch i sent you which adds code to the 
add_location_or_const_value_attribute routine.

Also, whether we generate a frame_base has *nothing* to do with the 
setting of TREE_PUBLIC.

The code says:

else if (!DECL_EXTERNAL (decl))
{
....


       /* Define the "frame base" location for this routine.  We use the
 	 frame pointer or stack pointer registers, since the RTL for local
 	 variables is relative to one of them.  */
       if (frame_base_decl && lookup_decl_loc (frame_base_decl) != NULL)
 	{
 	  add_location_or_const_value_attribute (subr_die, 
frame_base_decl,
 						 DW_AT_frame_base);
 	}
       else
 	{
 	  fp_reg
 	    = frame_pointer_needed ? hard_frame_pointer_rtx : 
stack_pointer_rtx;
 	  add_AT_loc (subr_die, DW_AT_frame_base, reg_loc_descriptor 
(fp_reg));
 	}

}

Re: gcc 4.0 generates location list without DW_AT_frame_base

[H. J. Lu]

On Fri, Dec 31, 2004 at 02:03:24PM -0800, H. J. Lu wrote:
> On Fri, Dec 31, 2004 at 04:57:17PM -0500, Daniel Berlin wrote:
> > >0x000000000055c84d in add_location_or_const_value_attribute
> > >(die=0x2a96205820,
> > >   decl=0x2a961ad000, attr=DW_AT_location)
> > >   at /export/gnu/src/gcc/gcc/gcc/dwarf2out.c:10108
> > >10108         descr = loc_descriptor (NOTE_VAR_LOCATION
> > >(node->var_loc_note),
> > >(gdb) p *loc_list
> > >$4 = {first = 0x0, last = 0x0, decl_id = 14047}
> > >(gdb)
> > 
> > Oh, that's weird.
> > Wonder why we added it then.
> > anyway, just change
> > if (loc_list)
> > to
> > if (loc_list && loc_list->first)
> 
> I am testing it now. Bootstrap has passed the previous failure. It will
> take a while to finish.

The modified patch works with tls_symbolic_operand in i386. However,
I do see

 <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
     DW_AT_sibling     : <427510>
     DW_AT_abstract_origin: <427159>
     DW_AT_low_pc      : 0x8399aea
     DW_AT_high_pc     : 0x8399b3c
 <3><4274a2>: Abbrev Number: 37 (DW_TAG_formal_parameter)
     DW_AT_abstract_origin: <42716b>
 <3><4274a7>: Abbrev Number: 37 (DW_TAG_formal_parameter)
     DW_AT_abstract_origin: <427177>
 <3><4274ac>: Abbrev Number: 44 (DW_TAG_lexical_block)
     DW_AT_low_pc      : 0x8399aea
     DW_AT_high_pc     : 0x8399b3c
 <4><4274b5>: Abbrev Number: 42 (DW_TAG_variable)
     DW_AT_abstract_origin: <427183>
     DW_AT_location    : 2 byte block: 91 54    (DW_OP_fbreg: -44)
[without DW_AT_frame_base]

I assume it is normal.


H.J.

Re: gcc 4.0 generates location list without DW_AT_frame_base

[Daniel Jacobowitz]

On Sat, Jan 01, 2005 at 11:15:00AM -0800, H. J. Lu wrote:
> The modified patch works with tls_symbolic_operand in i386. However,
> I do see
> 
>  <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
>      DW_AT_sibling     : <427510>
>      DW_AT_abstract_origin: <427159>
>      DW_AT_low_pc      : 0x8399aea
>      DW_AT_high_pc     : 0x8399b3c
>  <3><4274a2>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>      DW_AT_abstract_origin: <42716b>
>  <3><4274a7>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>      DW_AT_abstract_origin: <427177>

Do the abstract origins have locations?  Otherwise, that's a problem...

-- 
Daniel Jacobowitz

Re: gcc 4.0 generates location list without DW_AT_frame_base

[Daniel Berlin]

> I do see
>
> <2><427491>: Abbrev Number: 39 (DW_TAG_inlined_subroutine)
>     DW_AT_sibling     : <427510>
>     DW_AT_abstract_origin: <427159>
>     DW_AT_low_pc      : 0x8399aea
>     DW_AT_high_pc     : 0x8399b3c
> <3><4274a2>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>     DW_AT_abstract_origin: <42716b>
> <3><4274a7>: Abbrev Number: 37 (DW_TAG_formal_parameter)
>     DW_AT_abstract_origin: <427177>
> <3><4274ac>: Abbrev Number: 44 (DW_TAG_lexical_block)
>     DW_AT_low_pc      : 0x8399aea
>     DW_AT_high_pc     : 0x8399b3c
> <4><4274b5>: Abbrev Number: 42 (DW_TAG_variable)
>     DW_AT_abstract_origin: <427183>
>     DW_AT_location    : 2 byte block: 91 54    (DW_OP_fbreg: -44)
> [without DW_AT_frame_base]
>
> I assume it is normal.

No.
I'll fix the whole damn thing in a moment the right way (by having it 
verify the nearest enclosing subroutine die has a at_frame attribute and 
using that as the value of can_use_fb)

  >
>
> H.J.
>