This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]