This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] frame->frame => frame->addr && frame->base()
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 26 Apr 2002 10:58:14 -0400
- Subject: Re: [rfc] frame->frame => frame->addr && frame->base()
- References: <3CB5F868.8070001@cygnus.com>
> Hello,
>
> This comes from DanielB's and my discussion about dwarf2 CFA and dwarf2's frame_base vs GDB's frame->frame.
>
> An executive summary is that the two dwarf2 frame concepts (CFA and frame_base) do not go into one GDB frame (frame->frame).
>
> Because of this, I'd like to propose that the frame object have both:
>
> struct frame_info
> {
> ...
>
> // An ISA/ABI specific address within the ``specified frame'' that is constant throughout the lifetime of the frame. This address is used by GDB as a handle to identify this frame. This field must be initialized as part of the creation of a frame object. (see dwarf2 CFA)
>
> CORE_ADDR addr;
Hmm, MichaelS has pointed out (check the code for finding a frame) that
all we know about the existing frame->frame is that it is going to fall
somewhere in the range of stack addresses allocated to the function.
Making for an even more in-exact science, this ``in'' has poorly defined
boundary conditions - consider pre/post incr/decr SPs, ABIs that
allocate beyond SP and the like.
I guess, on the bright side, we now have it ``defined''. I'll update
the comments then try to think of a next move (suggestions?).
Andrew