Re: GDBARCH vs frame vs stacks

[Daniel Berlin <dan@www.cgsoftware.com>]

On Mon, 14 May 2001, Daniel Berlin wrote:

>
>
> On Sun, 13 May 2001, Andrew Cagney wrote:
>
> > Hello,
> >
> > Dan recently put forward a suggestion that the gdbarch code be changed
> > to be stackable so that a problem with the way GDB analizes frames. At
> > the time my gut reaction was ``no''. Given that part of the reaction was
> > based on gut feeling I should probably review and expand my comments -
> > it really felt like using an R.V. (1) for a road trip because someone
> > might want to BBQ a srimp. (Everyone knows that you use the exaust
> > manafold to BBQ things on road trips right? :-)
> >
> > Having had some more time to think about it I still think stacking
> > gdbarch to solve this problem is indeed wrong. In the below I'll try to
> > outline my rationale.
> >
> >
> > The architecture:
> >
> > The GDB architecture object carries with it a number of different pieces
> > of, sometimes orthongonaly, information: the ISA, the ABI, the SOLIBS,
> > debug/register info, ... Within these, all sorts of different
> > combnations are possible.
> >
> > For the GDBARCH vector, it was decided that, while many different
> > combinations are possible - a mesh - few at any would be active. It it
> > was also noted that, over time, sub components, would bubble to the
> > surface and be separated out. With this in mind, the gdbarch object was
> > made flat.
> >
> > In hindsite this was indeed the correct decision. It as facilitated a
> > relatively painless multi-arch conversion. It has also allowed
> > individual components, to indeed separate out - shlibs come to mind.
> >
> >
> > The frame:
> >
> > GDB's concept of a frame was deveoped back when the only thing of
> > interest was a VAX. Over time it has evolved and now some aspects of its
> > design are clearly showing their age - FP_REGNUM/READ_FP for instance.
> >
> > Examining the target code reveals, like you suggest, a very interesting
> > trait. Many targets, such as the prologue analysis functions, go through
> > a sequence like: try analysis using debug info; try analysis using
> > instructions; try analysis using tea leaves; punt (and not necessarily
> > in that order). When looking at such code, the reaction would indeed be
> > - hey stack!
> >
> >
> > Should GDBARCH therefor be stacked?
> >
> > The thing to remember is that, just because the frame code uses some
> > sort of ordered sequence (or is it an acyclic graph - that isn't even
> > clear) when doing its analysis, that sequence doesn't necessarily apply
> > to the entire GDBARCH vector. Per the above, the GDBARCH vector is
> > really a mesh.
> >
> > I think imposing a frame centric view on GDBARCH's mesh is wrong. The
> > the frame code, through re-design, should handle that.
> >
>
> > 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
^^^^^
I meant defined here, not used.
Since we don't support dwarf2 encapsulated in non-ELF right now anyway,
and none of the non-ELF object file readers support a format that does
have the kind of info we want,  the hooks for other objfile readers do
nothing.

--Dan