This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Problem with location lists and variables on stack
On Wed, Oct 01, 2003 at 06:03:18PM +0200, Josef Zlomek wrote:
> > > > > Let the local variables and (some) arguments be addressed using stack pointer,
> > > > > for example x86-64 architecture with variables addressed using %rsp.
> > > > > The address emitted for variables located on stack by my new patch is always
> > > > > DW_OP_fbreg + constant.
> > > > >
> > > > > When I was testing the emitted debug info with mainline GDB I found that
> > > > > GDB probably does not adjust addresses of variables when stack pointer changes
> > > > > (like because of "pushq" instruction) if using location lists.
> > > > > I think GDB should adjust the address of %rsp addressed variables according to
> > > > > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a
> > > > > better solution than emitting new locations to location list for all variables
> > > > > located on stack after each "push" and "pop" which would cause too large debug
> > > > > info.
> > > > >
> > > > > When I looked to gdb/dwarf2loc.c I see there:
> > > > > /* FIXME: cagney/2003-03-26: This code should be using
> > > > > get_frame_base_address(), and then implement a dwarf2 specific
> > > > > this_base method. */
> > > > > Probably this is related to my problem.
> > > >
> > > > The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base,
> > > > so it _ought_ to work.
> > > >
> > > > > I tested it on attached C file, assembler with debug info and x86-64 binary
> > > > > is attached too.
> > > >
> > > > Do you suppose you could produce an x86 (ia32) testcase? I don't have
> > > > x86-64 hardware available yet. The debug info looks right so I'd like
> > > > to get my fingers into the problem.
> > >
> > > Here is the x86 assembler.
> >
> > Thanks. I'll get back to you...
>
> Thanks.
What makes you believe that GDB is the problem? Here's the debug info
for argument "g":
<2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name : g
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_type : <ab>
DW_AT_location : 315 (location list)
Here's the location list:
0000013b 00000000 00000017 (DW_OP_fbreg: 28)
0000013b 00000017 00000083 (DW_OP_reg3)
0000013b 00000083 00000087 (DW_OP_fbreg: 28)
Here's the beginning of func1:
0x8048320 <func1>: push %ebp
0x8048321 <func1+1>: push %edi
0x8048322 <func1+2>: push %esi
0x8048323 <func1+3>: push %ebx
0x8048324 <func1+4>: sub $0x10,%esp
0x8048327 <func1+7>: mov 0x24(%esp,1),%eax
0x804832b <func1+11>: mov 0x2c(%esp,1),%edi
0x804832f <func1+15>: mov 0x38(%esp,1),%esi
i.e. those pushes are not accounted for in the debug info. This is
something that GCC must do when using -fomit-frame-pointer. To quote
from the DWARF spec:
The DW_OP_fbreg operation provides a signed LEB128 offset from the
address specified by the location description in the
DW_AT_frame_base attribute of the current function. (This is
typically a "stack pointer" register plus or minus some offset. On
more sophisticated systems it might be a location list that adjusts
the offset according to changes in the stack pointer as the PC
changes.)
The frame base is evaluated in the function's current context, not via
unwinding. So if GCC is using the CFA, then it needs to say so
somehow. It would be nice if it could reference the parent's stack
pointer somehow and save duplication. A mostly-relevant quote from the
spec:
In the context of supporting nested subroutines, the DW_AT_frame_base
attribute value should obey the following constraints:
1. It should compute a value that does not change during the life of
the procedure, and
>
> > Blast! Location list support for paramaters (as opposed to locals) was
> > added to GDB after 6.0 branched, and I never thought to move it over.
> > It's too late now, so it will have to go in 6.0.1.
>
> No problem.
>
> Josef
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer