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: [PATCH] -stack-info-frame/-stack-list-frames

On Thu, Apr 24, 2008 at 12:47:41AM +1200, Nick Roberts wrote:
>  > My biggest worry about this is that we'll be providing some information
>  > which is highly compiler dependent and which we cannot document in any way
>  > other that "it is hex number". I don't think a random frontend author knows
>  > what DWARF CFI is :-)
> If it was just a hex number, the concept of frame address presumably wouldn't
> exist.  To me, it refers to the start of the frame and if a variable has an
> address below that value, it belongs to that frame or a higher one.  Maybe on
> some architectures, the stack grows in the other direction, and maybe there are
> other anomalies, but a user could understand this and interpret such numbers.

My concern about this has been, and still is, that front ends will
assign more meaning to it than it really has.  This is one of the
trickiest parts of GDB.  We already use frame addresses (specifically
$fp) to create varobjs in non-current frames; this is basically the
only thing the entire complicated frame_base machinery is used for
when not using stabs and it really should go away.

How about we call it the stack address of the frame instead of the
frame address?  Then it can come from the unwound $sp, which will
be at the other end of the frame and is better defined.

Daniel Jacobowitz

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