RFA: DW_AT_frame_base fix for complicated frames

RFA: DW_AT_frame_base fix for complicated frames

[Daniel Jacobowitz]

Does anyone remember a specific reason why this code was there?  I don't,
and I rewrote all of this stuff... I am 99.99% sure it's based on the unwind
handling for saved registers, where we get either a register number or the
address of a stack slot.  But for frame bases that's not true:

A subroutine or entry point entry may also have a DW_AT_frame_base
attribute, whose value is a location description that computes the "frame
base" for the subroutine or entry point.

i.e. it computes the frame base.  Not the address of the frame base.  This
memory read tends to find (on x86) the return address, and then we think the
stack is at <main+34>.  Oopsie.

OK?  With this patch and some code Daniel Berlin and Joseph are working on,
location lists actually work.  I can see all the arguments in an
-fomit-frame-pointer function from the beginning.  It's really quite cool.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-10-02  Daniel Jacobowitz  <drow@mvista.com>

	* dwarf2expr.c (execute_stack_op): Don't treat the frame base as
	a memory pointer.

Index: dwarf2expr.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2expr.c,v
retrieving revision 1.9
diff -u -p -r1.9 dwarf2expr.c
--- dwarf2expr.c	22 Jul 2003 15:41:59 -0000	1.9
+++ dwarf2expr.c	2 Oct 2003 16:43:21 -0000
@@ -441,18 +441,6 @@ execute_stack_op (struct dwarf_expr_cont
 	    result = dwarf_expr_fetch (ctx, 0);
 	    if (ctx->in_reg)
 	      result = (ctx->read_reg) (ctx->baton, result);
-	    else
-	      {
-		char *buf = alloca (TARGET_ADDR_BIT / TARGET_CHAR_BIT);
-		int bytes_read;
-
-		(ctx->read_mem) (ctx->baton, buf, result,
-				 TARGET_ADDR_BIT / TARGET_CHAR_BIT);
-		result = dwarf2_read_address (buf,
-					      buf + (TARGET_ADDR_BIT
-						     / TARGET_CHAR_BIT),
-					      &bytes_read);
-	      }
 	    result = result + offset;
 	    ctx->stack_len = before_stack_len;
 	    ctx->in_reg = 0;

Re: RFA: DW_AT_frame_base fix for complicated frames

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> Does anyone remember a specific reason why this code was there?  I don't,
> and I rewrote all of this stuff... I am 99.99% sure it's based on the unwind
> handling for saved registers, where we get either a register number or the
> address of a stack slot.  But for frame bases that's not true:
> 
> A subroutine or entry point entry may also have a DW_AT_frame_base
> attribute, whose value is a location description that computes the "frame
> base" for the subroutine or entry point.
> 
> i.e. it computes the frame base.  Not the address of the frame base.  This
> memory read tends to find (on x86) the return address, and then we think the
> stack is at <main+34>.  Oopsie.
> 
> OK?  With this patch and some code Daniel Berlin and Joseph are working on,
> location lists actually work.  I can see all the arguments in an
> -fomit-frame-pointer function from the beginning.  It's really quite cool.

I think you're right, there's no reason for that memory fetch to be
there.  Please commit.

Re: RFA: DW_AT_frame_base fix for complicated frames

[Daniel Jacobowitz]

On Thu, Oct 02, 2003 at 12:54:32PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Does anyone remember a specific reason why this code was there?  I don't,
> > and I rewrote all of this stuff... I am 99.99% sure it's based on the unwind
> > handling for saved registers, where we get either a register number or the
> > address of a stack slot.  But for frame bases that's not true:
> > 
> > A subroutine or entry point entry may also have a DW_AT_frame_base
> > attribute, whose value is a location description that computes the "frame
> > base" for the subroutine or entry point.
> > 
> > i.e. it computes the frame base.  Not the address of the frame base.  This
> > memory read tends to find (on x86) the return address, and then we think the
> > stack is at <main+34>.  Oopsie.
> > 
> > OK?  With this patch and some code Daniel Berlin and Joseph are working on,
> > location lists actually work.  I can see all the arguments in an
> > -fomit-frame-pointer function from the beginning.  It's really quite cool.
> 
> I think you're right, there's no reason for that memory fetch to be
> there.  Please commit.

Thanks.  I've committed this to trunk and branch.  I also moved this to
the branch:

2003-10-09  Daniel Jacobowitz  <drow@mvista.com>

        Merge from mainline:
        2003-07-31  Daniel Jacobowitz  <drow@mvista.com>

        * dwarf2read.c (new_symbol): Use var_decode_location for parameters.

Location expressions and lists should work reasonably well on both now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: DW_AT_frame_base fix for complicated frames

[Andrew Cagney]

> Thanks.  I've committed this to trunk and branch.  I also moved this to
> the branch:
> 
> 2003-10-09  Daniel Jacobowitz  <drow@mvista.com>
> 
>         Merge from mainline:
>         2003-07-31  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * dwarf2read.c (new_symbol): Use var_decode_location for parameters.
> 
> Location expressions and lists should work reasonably well on both now.

Can you please add something to the NEWS file.  That way the 6.0.1 
announcement will include information letting the user decide if they 
need to upgrade.

Andrew

Re: RFA: DW_AT_frame_base fix for complicated frames

[Daniel Jacobowitz]

On Thu, Oct 09, 2003 at 11:14:19AM -0400, Andrew Cagney wrote:
> 
> >Thanks.  I've committed this to trunk and branch.  I also moved this to
> >the branch:
> >
> >2003-10-09  Daniel Jacobowitz  <drow@mvista.com>
> >
> >        Merge from mainline:
> >        2003-07-31  Daniel Jacobowitz  <drow@mvista.com>
> >
> >        * dwarf2read.c (new_symbol): Use var_decode_location for 
> >        parameters.
> >
> >Location expressions and lists should work reasonably well on both now.
> 
> Can you please add something to the NEWS file.  That way the 6.0.1 
> announcement will include information letting the user decide if they 
> need to upgrade.

Going through my email backlog...

Should I bother, or have we written off 6.0.1?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: DW_AT_frame_base fix for complicated frames

[Andrew Cagney]

> On Thu, Oct 09, 2003 at 11:14:19AM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >Thanks.  I've committed this to trunk and branch.  I also moved this to
>> >the branch:
>> >
>> >2003-10-09  Daniel Jacobowitz  <drow@mvista.com>
>> >
>> >        Merge from mainline:
>> >        2003-07-31  Daniel Jacobowitz  <drow@mvista.com>
>> >
>> >        * dwarf2read.c (new_symbol): Use var_decode_location for 
>> >        parameters.
>> >
>> >Location expressions and lists should work reasonably well on both now.
> 
>> 
>> Can you please add something to the NEWS file.  That way the 6.0.1 
>> announcement will include information letting the user decide if they 
>> need to upgrade.
> 
> 
> Going through my email backlog...
> 
> Should I bother, or have we written off 6.0.1?

I suspect 6.0.1 is a writeoff, but the NEWS entry in mainline will still 
help.

Andrew

Re: RFA: DW_AT_frame_base fix for complicated frames

[Daniel Jacobowitz]

On Mon, Nov 24, 2003 at 11:02:27AM -0500, Andrew Cagney wrote:
> >On Thu, Oct 09, 2003 at 11:14:19AM -0400, Andrew Cagney wrote:
> >
> >>
> >
> >>>Thanks.  I've committed this to trunk and branch.  I also moved this to
> >>>the branch:
> >>>
> >>>2003-10-09  Daniel Jacobowitz  <drow@mvista.com>
> >>>
> >>>        Merge from mainline:
> >>>        2003-07-31  Daniel Jacobowitz  <drow@mvista.com>
> >>>
> >>>        * dwarf2read.c (new_symbol): Use var_decode_location for 
> >>>        parameters.
> >>>
> >>>Location expressions and lists should work reasonably well on both now.
> >
> >>
> >>Can you please add something to the NEWS file.  That way the 6.0.1 
> >>announcement will include information letting the user decide if they 
> >>need to upgrade.
> >
> >
> >Going through my email backlog...
> >
> >Should I bother, or have we written off 6.0.1?
> 
> I suspect 6.0.1 is a writeoff, but the NEWS entry in mainline will still 
> help.

Good idea.  I've done this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-11-24  Daniel Jacobowitz  <drow@mvista.com>

	* NEWS: Mention improved location expression support.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.126
diff -u -p -r1.126 NEWS
--- NEWS	18 Oct 2003 18:41:22 -0000	1.126
+++ NEWS	24 Nov 2003 17:02:00 -0000
@@ -3,6 +3,12 @@
 
 *** Changes since GDB 6.0:
 
+* DWARF 2 Location Expressions
+
+GDB support for location expressions has been extended to support function
+arguments and frame bases.  Older versions of GDB could crash when they
+encountered these.
+
 * New native configurations
 
 NetBSD/amd64					x86_64-*-netbsd*