Identifying bottom-of-stack

Identifying bottom-of-stack

[Andrew Cagney]

Hello,

In the multi-threaded case, GDB's having fun identifying the outer-most 
(oldest) frame and, unfortunatly, has this habit of backtracing past it :-/

Does anyone see a problem with:

- GLIBC marking those outermost frames with CFI indicating that both the 
CFA and the RA are "unknown"?

- GDB's CFI unwinder recognizing this and returning a NULL frame ID (gdb 
doesn't unwind _past_ such a frame).

I think this would give us a portable way of terminating the stack.

comments?
Andrew

Re: Identifying bottom-of-stack

[Daniel Jacobowitz]

On Wed, Aug 04, 2004 at 12:00:50PM -0400, Andrew Cagney wrote:
> Hello,
> 
> In the multi-threaded case, GDB's having fun identifying the outer-most 
> (oldest) frame and, unfortunatly, has this habit of backtracing past it :-/
> 
> Does anyone see a problem with:
> 
> - GLIBC marking those outermost frames with CFI indicating that both the 
> CFA and the RA are "unknown"?
> 
> - GDB's CFI unwinder recognizing this and returning a NULL frame ID (gdb 
> doesn't unwind _past_ such a frame).
> 
> I think this would give us a portable way of terminating the stack.
> 
> comments?

This would make debugging in the outermost frame quite annoying,
wouldn't it?  We won't be able to find any frame relative variables.

I realize users rarely need to do this, but if we're going to design a
solution it should take this into account.

-- 
Daniel Jacobowitz

Re: Identifying bottom-of-stack

[Andrew Cagney]

> On Wed, Aug 04, 2004 at 12:00:50PM -0400, Andrew Cagney wrote:
> 
>>> Hello,
>>> 
>>> In the multi-threaded case, GDB's having fun identifying the outer-most 
>>> (oldest) frame and, unfortunatly, has this habit of backtracing past it :-/
>>> 
>>> Does anyone see a problem with:
>>> 
>>> - GLIBC marking those outermost frames with CFI indicating that both the 
>>> CFA and the RA are "unknown"?
>>> 
>>> - GDB's CFI unwinder recognizing this and returning a NULL frame ID (gdb 
>>> doesn't unwind _past_ such a frame).
>>> 
>>> I think this would give us a portable way of terminating the stack.
>>> 
>>> comments?
> 
> 
> This would make debugging in the outermost frame quite annoying,
> wouldn't it?  We won't be able to find any frame relative variables.

Why?  Frame relative variables us DW_AT_frame_base.

> I realize users rarely need to do this, but if we're going to design a
> solution it should take this into account.

Re: Identifying bottom-of-stack

[Daniel Jacobowitz]

On Wed, Aug 04, 2004 at 01:42:24PM -0400, Andrew Cagney wrote:
> >On Wed, Aug 04, 2004 at 12:00:50PM -0400, Andrew Cagney wrote:
> >
> >>>Hello,
> >>>
> >>>In the multi-threaded case, GDB's having fun identifying the outer-most 
> >>>(oldest) frame and, unfortunatly, has this habit of backtracing past it 
> >>>:-/
> >>>
> >>>Does anyone see a problem with:
> >>>
> >>>- GLIBC marking those outermost frames with CFI indicating that both the 
> >>>CFA and the RA are "unknown"?
> >>>
> >>>- GDB's CFI unwinder recognizing this and returning a NULL frame ID (gdb 
> >>>doesn't unwind _past_ such a frame).
> >>>
> >>>I think this would give us a portable way of terminating the stack.
> >>>
> >>>comments?
> >
> >
> >This would make debugging in the outermost frame quite annoying,
> >wouldn't it?  We won't be able to find any frame relative variables.
> 
> Why?  Frame relative variables us DW_AT_frame_base.

You're right.  I still have the nagging feeling there's some other
reason it matters, but since I can't think of specifics I'm probably
just hallucinating again.

-- 
Daniel Jacobowitz

Re: Identifying bottom-of-stack

[Andrew Cagney]

>>>This would make debugging in the outermost frame quite annoying,
>>>> >wouldn't it?  We won't be able to find any frame relative variables.
>>
>>> 
>>> Why?  Frame relative variables us DW_AT_frame_base.
> 
> 
> You're right.  I still have the nagging feeling there's some other
> reason it matters, but since I can't think of specifics I'm probably
> just hallucinating again.

Two things that might help:

- dwarf2-frame incorrectly returns the CFA as the ``frame_base''.  Other 
stuff means that the value isn't used (well except for info frame).

- this relies on GDB permitting an unwind into, but not past, a frame 
with a NULL ID.  The old code would have stopped things one frame short.

Andrew

Re: Identifying bottom-of-stack

[Roland McGrath]

Which machines are you talking about here that have a problem?  

On older architectures that worked before the advent of DWARF CFI, the
outermost frame of new threads as no DWARF CFI at all and has the frame
pointer register set to zero.  I assume that GDB's idea of "CFA" in a frame
without DWARF CFI is the value of the frame pointer register.  I also
assume that when the computed CFA is zero, GDB calls that "outermost".  
If these assumptions hold then there is no problem when the outermost frame
has no CFI at all (and zeroes the frame pointer).  Right?

On the x86-64, the code of the call that sets up the outermost frame
(clone) has CFI but is careful to make sure that it doesn't cover the code
that runs in the outermost frame of a new thread.  That code clears its
frame pointer before calling anyone.  So except for a small window of the
first few instructions a new thread runs before it's cleared its frame
pointer, my theory says there shouldn't be a problem for x86-64.
Is there one?

> - GLIBC marking those outermost frames with CFI indicating that both the 
> CFA and the RA are "unknown"?

What would such CFI look like exactly?  I am not much of an expert on
DWARF, but from my reading of the spec I can think of one way to encode
"unknown".  That is DW_CFA_def_cfa giving some register plus
DW_CFA_undefined for that register.  

AFAICS the spec doesn't say anything like "a computed CFA value of zero
means the outermost frame".  But at a guess that this is how it would
always be determined, another option is just DW_CFA_def_cfa giving a
register that is in fact zero in actual frames.

Is this the kind of thing you have in mind?



Thanks,
Roland

Re: Identifying bottom-of-stack

[Mark Kettenis]

   Date: Wed, 4 Aug 2004 12:02:47 -0700
   From: Roland McGrath <roland@redhat.com>

   On older architectures that worked before the advent of DWARF CFI, the
   outermost frame of new threads as no DWARF CFI at all and has the frame
   pointer register set to zero.  I assume that GDB's idea of "CFA" in a frame
   without DWARF CFI is the value of the frame pointer register.  I also
   assume that when the computed CFA is zero, GDB calls that "outermost".  
   If these assumptions hold then there is no problem when the outermost frame
   has no CFI at all (and zeroes the frame pointer).  Right?

The problem is that a zero frame pointer is an insufficient condition
to determine the bottom of the stack.  With code generated with
-fno-frame-pointer, the register that was traditionally used for the
frame pointer can be used for other purposes, and may very well
contain zero.

   On the x86-64, the code of the call that sets up the outermost frame
   (clone) has CFI but is careful to make sure that it doesn't cover the code
   that runs in the outermost frame of a new thread.  That code clears its
   frame pointer before calling anyone.  So except for a small window of the
   first few instructions a new thread runs before it's cleared its frame
   pointer, my theory says there shouldn't be a problem for x86-64.
   Is there one?

There is.  On amd64 -fno-frame-pointer is the default.  So this effort
of not generating CFI and clearing the framepointer is pointless.

   > - GLIBC marking those outermost frames with CFI indicating that both the 
   > CFA and the RA are "unknown"?

Andrew, please choose your wording carefully.  We now have,
"unspecified", "undefined", "unknown".  It's all very much unclear
what we mean by that.  I'm very uncomfortable with using any of
these..  Let's specify things in an explicit way if we're going to
specify something at all.

Mark

Re: Identifying bottom-of-stack

[Andrew Cagney]

>    > - GLIBC marking those outermost frames with CFI indicating that both the 
>    > CFA and the RA are "unknown"?

s/unknown/undefined/

Andrew

Re: Identifying bottom-of-stack

[Roland McGrath]

> The problem is that a zero frame pointer is an insufficient condition
> to determine the bottom of the stack.  With code generated with
> -fno-frame-pointer, the register that was traditionally used for the
> frame pointer can be used for other purposes, and may very well
> contain zero.

Of course, but if there is no CFI then there is nothing better to do than
assume the frame pointer is a frame pointer and try to use it, no?

> There is.  On amd64 -fno-frame-pointer is the default.

I know that.

> So this effort of not generating CFI and clearing the framepointer is
> pointless.

Clearing the frame pointer is not pointless since the ABI document suggests
doing exactly that.  Avoiding generating CFI is not pointless since it is
better than generating CFI that is incorrect.

Anyway, I didn't ask if these things were pointless, I asked if they were
sufficient.  If gdb doesn't consider a zero frame pointer register in a
frame with no CFI sufficient indication of being the outermost frame, then
that answers the question.  You don't need to justify the choice of gdb's
semantics on this to me, just clarify them to me.

[Andrew says:]
> >    > - GLIBC marking those outermost frames with CFI indicating that both the 
> >    > CFA and the RA are "unknown"?
> 
> s/unknown/undefined/

Perhaps this addresses Mark's request for precision in terminology, but it
doesn't clarify anything for me.  Does this "undefined" mean the
"undefined" used in the DWARF spec?  Does DW_CFA_def_cfa with some register +
DW_CFA_undefined on that register in fact yield this?  Is that the only way
to produce it?  Is it the optimal way?

These are the questions I meant to imply when I asked,
"What would such CFI look like exactly?" 

If you want me to do it, step one is always to specify it completely.


Thanks,
Roland

Re: Identifying bottom-of-stack

[Andrew Cagney]

> [Andrew says:]
> 
>>>> >    > - GLIBC marking those outermost frames with CFI indicating that both the 
>>>> >    > CFA and the RA are "unknown"?
>>
>>> 
>>> s/unknown/undefined/
> 
> 
> Perhaps this addresses Mark's request for precision in terminology, but it
> doesn't clarify anything for me.  Does this "undefined" mean the
> "undefined" used in the DWARF spec?  Does DW_CFA_def_cfa with some register +
> DW_CFA_undefined on that register in fact yield this?  Is that the only way
> to produce it?

Yes.  CFA's "undefined", that would yield what we need.

 > Is it the optimal way?

I don't know.

> These are the questions I meant to imply when I asked,
> "What would such CFI look like exactly?" 
> 
> If you want me to do it, step one is always to specify it completely.

I gather that no one's found a hole in the theory, I guess it is time to 
prototype it in, I guess, GDB's testsuite.

Andrew