Re: [RFA] parse_frame_specification (stack.c)

[Fernando Nasser <fnasser@cygnus.com>]

My thoughts exactly.  I did not know of any examples with 4K frames though.
But we seem to have been outnumbered in the "*" approach :-)

We can adopt an heuristic that assumes "4" as a stack level and "0x4" as a frame address, thus given the user a chance to break the ambiguity (i.e. decimals are stack levels and hex numbers are addresses). We add this note to the manual and perhaps to the help.  But what would we do with computed values like "frame $var12"?  Conversely, "frame $var12" and "frame *$var12" are certainly different.

I still think the "*" is the only definitive solution.

Fernando  





Eli Zaretskii wrote:
> 
On Mon, 5 Mar 2001, Fernando Nasser wrote:

> Maybe we should start requiring the * for addresses and if not assuming
> it is a stack level (small integer as you say) and update the manual
> accordingly.

I agree.

> On Mon, 5 Mar 2001, Fernando Nasser wrote:
> 
> > Maybe we should start requiring the * for addresses and if not assuming
> > it is a stack level (small integer as you say) and update the manual
> > accordingly.
> 
> I agree.

On Mon, 5 Mar 2001, Fernando Nasser wrote:

> But, anyway, frames at very low addresses are not very likely so I guess
> we should just leave things as they are.

How low is ``low''?

The lowest possible frame address is 0x1000, I guess (for a
hypothetical architecture which leaves only the null page uncommitted
and has its stack right after that).  Is it unreasonable to expect 4K
frames?  I don't think so; I once had to debug a program with infinite
recursion, where I needed to wade through 750K(!) frames.  As another
data point, Emacs during garbage collection routinely uses 10K or more
recursive invocations of mark_object function and its ilk.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9