[rfc] frame->frame => frame->addr && frame->base()

[rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

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;

// High level language concept of the base address of a frame.  Often 
refered to as ``frame_base'' or ``frame pointer''.  This value should 
only be computed on-demand.  It is strongly recommended, though, that 
implementations cache the computed value in the frame cache.  The method 
is initialized as part of the frame objects creation.  The default 
method returns frame->addr.  (see dwarf2 DW_AT_frame_base)

CORE_ADDR (*base) (struct frame_info *frame);

...
}


Thoughts?

Andrew

Re: [rfc] frame->frame => frame->addr && frame->base()

[Kevin Buettner]

On Apr 11,  4:56pm, Andrew Cagney wrote:

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

I like this.  I find frame->frame confusing.  Also, I like it that
you're documenting the fact that this value remains constant over the
lifetime of the frame.  I think we have a number of targets which
don't get this right.

> // High level language concept of the base address of a frame.  Often 
> refered to as ``frame_base'' or ``frame pointer''.  This value should 
> only be computed on-demand.  It is strongly recommended, though, that 
> implementations cache the computed value in the frame cache.  The method 
> is initialized as part of the frame objects creation.  The default 
> method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
> 
> CORE_ADDR (*base) (struct frame_info *frame);

This translates the CFA (canonical frame address) into an address that's
useful for some other purpose, right?  What are the purposes that it
would be used for?

(My worry is that there may be more than one translation which might
prove to be useful.)

Kevin

Re: [rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

> // High level language concept of the base address of a frame.  Often 
>> refered to as ``frame_base'' or ``frame pointer''.  This value should 
>> only be computed on-demand.  It is strongly recommended, though, that 
>> implementations cache the computed value in the frame cache.  The method 
>> is initialized as part of the frame objects creation.  The default 
>> method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
>> 
>> CORE_ADDR (*base) (struct frame_info *frame);
> 
> 
> This translates the CFA (canonical frame address) into an address that's
> useful for some other purpose, right?  What are the purposes that it
> would be used for?

Strictly speaking it doesn't translate a CFA.  The CFA is something 
private to the CFI code.   It is just that it happens to evaluate to the 
same value.

In dwarf2, the debug info may indicate that both ->addr and ->base have 
the value of [r31]+10.

> (My worry is that there may be more than one translation which might
> prove to be useful.)

True.

The intent is for dwarf2 where a location expression can contain 
references to ``fpreg''.  That is really a reference to the current 
value of DW_AT_frame_base.  I guess the comment should emphasize how it 
relates to debug info and the debug ``frame base'' register.

Andrew

Re: [rfc] frame->frame => frame->addr && frame->base()

[Richard Earnshaw]

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

The main advantage of the DWARF CFA is that it is, as I understand it, 
precisely defined on all systems (something like: the value of the stack 
pointer when executing the first instruction of a function).  As such, it 
will always be valid, and cannot change while executing the function.

> // High level language concept of the base address of a frame.  Often 
> refered to as ``frame_base'' or ``frame pointer''.  This value should 
> only be computed on-demand.  It is strongly recommended, though, that 
> implementations cache the computed value in the frame cache.  The method 
> is initialized as part of the frame objects creation.  The default 
> method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
> 
> CORE_ADDR (*base) (struct frame_info *frame);

What would this mean in the context of a function that doesn't use a frame 
pointer?  What about a leaf function which doesn't store anything on the 
stack?  I can't see how this can have any MI interpretation (other than 
the fact that all functions in a nested chain should have a different 
value).

R.

Re: [rfc] frame->frame => frame->addr && frame->base()

[Richard Earnshaw]

Rather than worrying in detail about what should be held in the "frame" 
structure, shouldn't we be more concerned with the methods that need to 
access the frame?  Once we have that, what needs to be stored should 
become obvious.

R.

Re: [rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

>> // 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;
> 
> 
> The main advantage of the DWARF CFA is that it is, as I understand it, 
> precisely defined on all systems (something like: the value of the stack 
> pointer when executing the first instruction of a function).  As such, it 
> will always be valid, and cannot change while executing the function.

Yes.  Remember that a CFA tells you nothing about the location of 
variables or arguments on the stack.  Also remember that at present, no 
one is quite sure what frame->frame means - as KevinB pointed out the 
``constant'' property is new.  I suspect the property most likely 
doesn't hold for some existing ISAs (sigh).

>> // High level language concept of the base address of a frame.  Often 
>> refered to as ``frame_base'' or ``frame pointer''.  This value should 
>> only be computed on-demand.  It is strongly recommended, though, that 
>> implementations cache the computed value in the frame cache.  The method 
>> is initialized as part of the frame objects creation.  The default 
>> method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
>> 
>> CORE_ADDR (*base) (struct frame_info *frame);
> 
> 
> What would this mean in the context of a function that doesn't use a frame 
> pointer?  What about a leaf function which doesn't store anything on the 
> stack?  I can't see how this can have any MI interpretation (other than 
> the fact that all functions in a nested chain should have a different 
> value).

The value is debug-info dependant.  See section 3.3.5 of the dwarf2 
spec.  For some frames this value may not even be applicable - that is 
ok because it isn't a requirement of a frame.

It looks like, in a sense this method is already present, check 
FRAME_ARGS_ADDRESS_CORRECT.

enjoy,
Andrew

Re: [rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

> Rather than worrying in detail about what should be held in the "frame" 
> structure, shouldn't we be more concerned with the methods that need to 
> access the frame?  Once we have that, what needs to be stored should 
> become obvious.
> 
> R.

I'm not too worried by the methods used to access a frame (once 
created).  I'm trying to focus in on just the frame creation phase.  In 
theory, the code should look like:

	create_frame (frame_addr, frame_pc /*I'm loosing that one :-)*/,
		frame_next);

The reality - get_prev_frame() - is unfortunatly, very very different. 
To appreciate ``the quality'' of the current situtation, grep for '->pc 
= ' and '->frame = ' in the tdep.c code, and look at how SP_REGNUM is 
special cased in frame->saved_regs[].

Still, I've had some success.  The code I've got is starting to look 
like the above while still keeping the existing code working - even has 
a cache :-)

enjoy,
Andrew

Re: [rfc] frame->frame => frame->addr && frame->base()

[Kevin Buettner]

On Apr 12,  9:38am, Andrew Cagney wrote:

> >> // High level language concept of the base address of a frame.  Often 
> >> refered to as ``frame_base'' or ``frame pointer''.  This value should 
> >> only be computed on-demand.  It is strongly recommended, though, that 
> >> implementations cache the computed value in the frame cache.  The method 
> >> is initialized as part of the frame objects creation.  The default 
> >> method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
> >> 
> >> CORE_ADDR (*base) (struct frame_info *frame);
> > 
> > What would this mean in the context of a function that doesn't use a frame 
> > pointer?  What about a leaf function which doesn't store anything on the 
> > stack?  I can't see how this can have any MI interpretation (other than 
> > the fact that all functions in a nested chain should have a different 
> > value).
> 
> The value is debug-info dependant.  See section 3.3.5 of the dwarf2 
> spec.  For some frames this value may not even be applicable - that is 
> ok because it isn't a requirement of a frame.

If the value returned by frame->base() is debug-info dependent, then
that would suggest that it could have different values for different
types of debug info.  That in turn suggests that you have to know what
type of debug info you're dealing with at frame creation time so that
frame->base can be initialized correctly.

Of course, it could be done lazily.  You could just initialize frame->base
to lazy_base() (or whatever).  lazy_base() would determine the function
that's really required for that frame + debug info, reset the ->base
field, and then invoke the function it's just calculated to obtain the
desired value.

Implementation details aside, this dependency causes me to wonder if it's
really a good idea make this operation a member of the frame struct.

Kevin

Re: [rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

> If the value returned by frame->base() is debug-info dependent, then
> that would suggest that it could have different values for different
> types of debug info.  That in turn suggests that you have to know what
> type of debug info you're dealing with at frame creation time so that
> frame->base can be initialized correctly.

yes.

> Of course, it could be done lazily.  You could just initialize frame->base
> to lazy_base() (or whatever).  lazy_base() would determine the function
> that's really required for that frame + debug info, reset the ->base
> field, and then invoke the function it's just calculated to obtain the
> desired value.
> 
> Implementation details aside, this dependency causes me to wonder if it's
> really a good idea make this operation a member of the frame struct.

I'm still working through that.  If different frames have different 
debug info then they would need different functions.

Initially, I suspect a frame->frame => frame->addr change will go 
through but not a new frame->base() method.  It may not be necessary - 
FRAME_ARGS_ADDRESS_CORRECT appears to be equivalent.  Unfortunatly, 
frame_args_address_correct is bound to the ABI/ISA and not, also, the 
debug info.

Andrew

Re: [rfc] frame->frame => frame->addr && frame->base()

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:

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

If this needs to be equal to the Dwarf 2 CFA value, it seems to me the
comment should say that explicitly.  Of course the explanation
shouldn't be specific to any debug format, but it should relate its
meaning to various interesting debug formats; see my suggested text
below.

> // High level language concept of the base address of a frame.  Often
> refered to as ``frame_base'' or ``frame pointer''.  This value should
> only be computed on-demand.  It is strongly recommended, though, that
> implementations cache the computed value in the frame cache.  The
> method is initialized as part of the frame objects creation.  The
> default method returns frame->addr.  (see dwarf2 DW_AT_frame_base)
> 
> CORE_ADDR (*base) (struct frame_info *frame);

Same here --- I think the comment needs to be more explicit on what
this function's value must mean.  For example:

   Function that returns the frame's base address, for local variable
   references.  Most debug info formats describe the locations of
   stack-based local variables as offsets from some assumed base
   address; exactly what that base address is (frame pointer register?
   stack pointer?) varies from machine to machine.  Whatever the case,
   this function computes that base address.

   For Dwarf 2, the base address is the value given by the function's
   DW_AT_frame_base attribute, and the value that the DW_OP_fbreg
   instruction pushes; for STABS, the value of an N_LSYM stab is the
   offset from this base address to the variable.

Re: [rfc] frame->frame => frame->addr && frame->base()

[Andrew Cagney]

> 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