This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG
- From: Daniel Berlin <dan at dberlin dot org>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 6 Apr 2002 21:08:01 -0500 (EST)
- Subject: Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG
On Sat, 6 Apr 2002, Andrew Cagney wrote:
> > and
> >>
> >
> >> > - the frame base address (for DW_OP_fbreg)
> >> >
> >> >
> >> > Not possible.
> >> > the frame base can be a location list.
> >> > That's why it pulls it out of the frame function on the fly.
> >
> >>
> >> Something I've never understood. Shouldn't frame_base be stored in
> >> frame->base as part of the initial frame creation. Hence avoiding this
> >> recursion?
> >
> >
> > Theoretically you could, but it's sort of pointless.
> > You still end up doing the same lookup.
> > It also hides the code, since the code to create frames is nowhere
> > near the dwarf2 reader.
>
> I'm still missing something. If dwarf2 info isn't used to compute
> frame->base (and frame->prev->pc) where are the values comming from?
I'm confused now.
I grepped for frame->base, and find no occurrences of it.
Anyway, DW_OP_fbreg has a special meaning.
It specifically means "Use the value you get from evaluating the
DW_AT_frame_base attribute of the current function". So that's what we do.
Even more specifically, "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."
I'm just doing what the spec says, nothing more, nothing less.
:)
> > Andrew
>