This is the mail archive of the 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: info frame

Eli Zaretskii wrote:

>> Date: Sun, 16 Apr 2006 21:33:43 -0400
>> From: Daniel Jacobowitz <>
>> Cc: Mark Kettenis <>,
>> > >>      553^done,stack=[frame=
>> > >>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>> > 
>> > 0xbffff2c0 should not be the value of $fp but the value of "frame
>> > at..." in 'info frame`?
>> In fact, it's like that it will be the "frame at" address.
> Daniel, I cannot parse this sentence, and consequently I cannot figure
> out what are you saying in general.
>> But I don't
>> think it would be wise to architect that into the interface; I think I
>> explained why earlier, but if not, it's because this is a touchy
>> internal interface for GDB.  If you want to display it to the user, you
>> might want something different - either explicitly the $sp, or
>> explictly the architectural $fp register, or explicitly the call frame
>> address.  If you want to use it in a frontend, then all we should offer
>> is an opaque ID for equality testing, IMHO.
> Are you saying that the "frame at ..." part in the CLI output is
> meaningless for users?  If so, why do we show it at all?

Well, "info frame" is documented to print absolutely all information about a
frame. And frame base address is part of "all information".

I would not want that field to go away, at least not until frame id is
exposed via some other command.

- Volodya

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