From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Andrew Cagney Cc: GDB Patches Subject: Re: GDBARCH vs frame vs stacks Date: Mon, 14 May 2001 14:57:00 -0000 Message-id: References: <3AFEAF00.6090605@cygnus.com> X-SW-Source: 2001-05/msg00315.html 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 .... >