GDBARCH vs frame vs stacks

[Andrew Cagney <ac131313 at cygnus dot com>]

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.

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