From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Berlin Cc: GDB Patches Subject: Re: GDBARCH vs frame vs stacks Date: Tue, 15 May 2001 11:52:00 -0000 Message-id: <3B017AE9.5060106@cygnus.com> References: X-SW-Source: 2001-05/msg00327.html > 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. What I have in mind is rationalization of the frame object so that it does less not more. To me the problem is that the frame abstraction is confused - not suprising given it has evolved over time. The recent proposals to sort out the register interface is an example. It actually ends up with a smaller simpler interface. Hopefully it is possible to look at the dwarf2 abstraction model and find something that is common to both it and the other debug systems. Andrew