Re: GDBARCH vs frame vs stacks

[Daniel Berlin <dan at www dot cgsoftware dot com>]

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
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.

However, it does bother me that you keep brining up a dwarf2 centric view
whenever i mention using dwarf2 for this or that.  I only talk about it
because it's the only thing that is very widely used, and supports
optimized debugging to a very large extent.  I don't believe i've ever
proposed anything that I planned to implement in a way that other debug
formats couldn't use it (even the location list stuff isn't dwarf2
specific, i just only implemented support in the dwarf2 reader. There
really isn't another way to decribe the location of something in a way
you can evaluate at runtime  other than some kind of stack machine and
opcodes.), nor would I.
It really bothers me how much of the symbol table stuff is completely
designed to be an in memory structure for, well, stabs (or some
equivalent but not using strings format), rather than designed to be a
good symbol table interface.
Things like partial symbols being required, when >1 debug format we
support not only doesn't need them, but they waste time and memory to use
them. It's a complete lose.  I am very careful and try to not make the
same type of mistake.

I wouldn't even have to complain so much if the symbol table stuff didn't
force things onto debug format readers.  Heck, most formats these days
actually have almost no need for a real, honest to god symbol table
somewhere in  memory. I know of at least three debuggers that just lookup
the symbol direct in the debug info (since most formats have the indexes
necesary),  and read it into whatever symbol structure on the fly.  They
then just have some cache to retain some x megabytes of last used symbols.

I was, however, planning to look at frames in a few months, since I want
to be able to fake frames for inline functions, etc.
--Dan
 > > Andrew
>
>
> (1) An R.V. is like a campervan but far more grand. Think of a seriously
> oversize bus. Typically seen towing a large 4wd (S.R.V.) towing a small
> car ....
>