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 15:14:00 -0000 Message-id: References: X-SW-Source: 2001-05/msg00316.html 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