This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: GDBARCH vs frame vs stacks
- To: Daniel Berlin <dan at www dot cgsoftware dot com>
- Subject: Re: GDBARCH vs frame vs stacks
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 15 May 2001 14:52:25 -0400
- Cc: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- References: <Pine.LNX.4.33.0105141729090.7473-100000@www.cgsoftware.com>
> Rather than dumping the problem on gdbarch, I think the thing to do is
>> review the way that core-gdb interacts with a frame and determine an
>> interaction model that accomodates both existing abi and abi's based
>> around dwarf2 info. In doing this, the end result should be a good clean
>> understandable (and not dwarf2 centric) design.
>
>
> Sure. I just didn't want to resdesign the frame ATM, to be honest, because
> it would open up a can of worms since i'm sure everyone has *something*
> they want frames to be able to do, that they don't do now, and thus, i'd
> be getting myself into too much ATM. There was nothing dwarf2 specific
> about my current interjection into *_get_saved_register, in actuality. I
> had added a symbol file hook (well two) for getting and evaluating call frame
> info, and made the elf reader (which is where these hooks are acutally
> used) call through to dwarf2's getting and evaluating routines (because no
> other formats we currently support support it). All i had added to the
> actual *_get_saved_register routines was the code to get the objfile for
> the frame function, and call through to it's hook.
What I have in mind is rationalization of the frame object so that it
does less not more. To me the problem is that the frame abstraction is
confused - not suprising given it has evolved over time.
The recent proposals to sort out the register interface is an example.
It actually ends up with a smaller simpler interface.
Hopefully it is possible to look at the dwarf2 abstraction model and
find something that is common to both it and the other debug systems.
Andrew