Stepping over longjmp presumably broken for glibc

Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

GDB sets breakpoints at longjmp, and when it hits one, it fetches the
address of the jmp_buf, reads the PC from it, sets a breakpoint at that PC,
and continues.  This needs to be redone, probably to single-step.  Current
versions of glibc for many platforms xor the saved PC with a randomized
canary, so setting a breakpoint at that "address" isn't going to work
especially well.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 12/22/05, Daniel Jacobowitz <drow@false.org> wrote:
> Current
> versions of glibc for many platforms xor the saved PC with a randomized
> canary

African, or European?

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Thu, 22 Dec 2005 16:17:34 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: libc-alpha@sourceware.org
> 
> Current versions of glibc for many platforms xor the saved PC with a
> randomized canary, so setting a breakpoint at that "address" isn't
> going to work especially well.

How does glibc restore the correct address when you call longjmp?  Do
they save the canary in some place, or something?

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Dec 23, 2005 at 10:25:04AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 22 Dec 2005 16:17:34 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: libc-alpha@sourceware.org
> > 
> > Current versions of glibc for many platforms xor the saved PC with a
> > randomized canary, so setting a breakpoint at that "address" isn't
> > going to work especially well.
> 
> How does glibc restore the correct address when you call longjmp?  Do
> they save the canary in some place, or something?

Yes.  However, where it is safed is not a public ABI, and varies wildly
by architecture; I wouldn't care to try to reverse it in GDB, personally.
For instance, during ld.so bootstrapping it's in a global variable
named __pointer_chk_guard; if the platform supports TLS, then later in
execution it will be at some architecture-dependent offset from the
thread pointer.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Fri, 23 Dec 2005 08:20:40 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> > How does glibc restore the correct address when you call longjmp?  Do
> > they save the canary in some place, or something?
> 
> Yes.  However, where it is safed is not a public ABI, and varies wildly
> by architecture; I wouldn't care to try to reverse it in GDB, personally.

So how would you suggest to solve this?

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Dec 23, 2005 at 05:16:53PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 23 Dec 2005 08:20:40 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sourceware.org
> > 
> > > How does glibc restore the correct address when you call longjmp?  Do
> > > they save the canary in some place, or something?
> > 
> > Yes.  However, where it is safed is not a public ABI, and varies wildly
> > by architecture; I wouldn't care to try to reverse it in GDB, personally.
> 
> So how would you suggest to solve this?

If I'd had a good idea I'd have included it in my original post :-)

Probably, we need to single-step until we're out of longjmp, taking
special care of any architecture which calls functions from longjmp (I
don't know of any, but I bet there is one somewhere).  I don't know if
we can do that without infrastructure changes or not.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Fri, 23 Dec 2005 10:20:21 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Probably, we need to single-step until we're out of longjmp, taking
> special care of any architecture which calls functions from longjmp (I
> don't know of any, but I bet there is one somewhere).  I don't know if
> we can do that without infrastructure changes or not.

Wouldn't it be easier to talk to glibc developers into setting up an
API for revealing the PC?

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Dec 23, 2005 at 07:07:23PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 23 Dec 2005 10:20:21 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > Probably, we need to single-step until we're out of longjmp, taking
> > special care of any architecture which calls functions from longjmp (I
> > don't know of any, but I bet there is one somewhere).  I don't know if
> > we can do that without infrastructure changes or not.
> 
> Wouldn't it be easier to talk to glibc developers into setting up an
> API for revealing the PC?

I think that would be just as complicated as single-stepping out of
longjmp, with the added downside of greater coordination between the
debugger and runtime (additional points of failure).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Fri, 23 Dec 2005 12:09:13 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> with the added downside of greater coordination between the
> debugger and runtime (additional points of failure).

We already have this downside (in many parts of GDB, not only in this
particular situation), so continuing with that won't be a change for
the worse.

If glibc maintainers actively fight the debugger's ability to debug
their code, we will never succeed in catching up with them.  So I'd
rather they stopped with that attitude and started cooperating with
us.  I can ask RMS to try to influence the glibc team, if you think
this will help.

Re: Stepping over longjmp presumably broken for glibc

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi,

Eli Zaretskii wrote:

> If glibc maintainers actively fight the debugger's ability to debug
> their code, we will never succeed in catching up with them.  So I'd
> rather they stopped with that attitude and started cooperating with
> us.  I can ask RMS to try to influence the glibc team, if you think
> this will help.

I think it's another issue of debug vs. non-debug binaries. Any debugger 
will have a hard time finding the end of a higher-language construct in 
a non-debug binary. A debug binary on the other hand should not intermix 
constructs and take care to have enough hints for the debugger to find 
out stuff. A glibc for debugging should hence store usable pointers, and 
people should use a debug build when debugging the glibc.

    Simon aka Captain Obvious

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Fri, 23 Dec 2005 19:01:07 +0100
> From: Simon Richter <Simon.Richter@hogyros.de>
> Cc: gdb@sourceware.org
> 
> Eli Zaretskii wrote:
> 
> > If glibc maintainers actively fight the debugger's ability to debug
> > their code, we will never succeed in catching up with them.  So I'd
> > rather they stopped with that attitude and started cooperating with
> > us.  I can ask RMS to try to influence the glibc team, if you think
> > this will help.
> 
> I think it's another issue of debug vs. non-debug binaries. Any debugger 
> will have a hard time finding the end of a higher-language construct in 
> a non-debug binary. A debug binary on the other hand should not intermix 
> constructs and take care to have enough hints for the debugger to find 
> out stuff. A glibc for debugging should hence store usable pointers, and 
> people should use a debug build when debugging the glibc.

Are we talking about the same thing?  I'm not talking about stepping
inside setjmp and longjmp, I'm talking about stepping thru code that
calls longjmp.  When you `step' or `next' thru such a code, you want
GDB to follow the jump as the running code will.  This should happen
even if the library does not have debugging info in it.

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Dec 23, 2005 at 07:46:09PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 23 Dec 2005 12:09:13 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > with the added downside of greater coordination between the
> > debugger and runtime (additional points of failure).
> 
> We already have this downside (in many parts of GDB, not only in this
> particular situation), so continuing with that won't be a change for
> the worse.

Sorry, but I think it will.  The only two places that come to mind for
glibc are the shared library list and libthread_db; both are constant
sources of bugs and aggrevation.  Not so much for the native case, but
I work with a lot of people who use remote debugging, and answer many
questions about it on gdb@.

Also, as a general principle, I aim to keep the debugger as fully
isolated from the debuggee as possible.  I spend a lot of time
debugging the C runtime, and the bits where GDB tries to "cooperate"
with it are extremely frustrating in that case.  When I have some more
time for it, I'll be further reducing our dependence on glibc for
threads.

> If glibc maintainers actively fight the debugger's ability to debug
> their code, we will never succeed in catching up with them.  So I'd
> rather they stopped with that attitude and started cooperating with
> us.  I can ask RMS to try to influence the glibc team, if you think
> this will help.

I'm not sure where you're going with this.  It's not greater _human_
coordination that I'm objecting to, it's greater _machine_
coordination; version skew between glibc and gdb, support for old and
new versions, et cetera.  The hooks would not get a lot of use, and
would be very complicated - I can say the former based on the fact that
no one's noticed the problem yet (I found it by code inspection), and
the latter based on studying the implementation.  Complicated means
fragile.

I think that a solution which does not rely on support from the runtime
being debugged is inherently superior to one which does.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Sat, 24 Dec 2005 11:23:02 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Dec 23, 2005 at 07:46:09PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 23 Dec 2005 12:09:13 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > with the added downside of greater coordination between the
> > > debugger and runtime (additional points of failure).
> > 
> > We already have this downside (in many parts of GDB, not only in this
> > particular situation), so continuing with that won't be a change for
> > the worse.
> 
> Sorry, but I think it will.  The only two places that come to mind for
> glibc are the shared library list and libthread_db

What about the symbols we use when we look for specific functions,
like malloc and fork?

I also don't see any significant difference between dependencies on
intimate details of the runtime library and the details of the ABI,
like function prologue emitted by GCC.  We depend on that in lots of
places.

> Also, as a general principle, I aim to keep the debugger as fully
> isolated from the debuggee as possible.

I agree in principle, but given that we already depend on that, is
there any reason to resist in this single case?

  I spend a lot of time
> debugging the C runtime, and the bits where GDB tries to "cooperate"
> with it are extremely frustrating in that case.  When I have some more
> time for it, I'll be further reducing our dependence on glibc for
> threads.
> 
> I think that a solution which does not rely on support from the runtime
> being debugged is inherently superior to one which does.

If we can find one, and if it is not fragile, then I agree 110%.

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Sat, Dec 24, 2005 at 06:36:17PM +0200, Eli Zaretskii wrote:
> > Sorry, but I think it will.  The only two places that come to mind for
> > glibc are the shared library list and libthread_db
> 
> What about the symbols we use when we look for specific functions,
> like malloc and fork?

Ah.  I think there's a very important difference between the cases I
described and these: Malloc, and fork, and function calling, are all
public interfaces.  They're described by standards.  We don't need to
know anything about the particular implementation in order to use them.

But there's no standard to cover what we need here - jmp_buf's
deliberately an opaque type.

> I also don't see any significant difference between dependencies on
> intimate details of the runtime library and the details of the ABI,
> like function prologue emitted by GCC.  We depend on that in lots of
> places.

I have less of an argument for this one, but I still do think there's a
difference.  This is a static dependence rather than a dynamic
dependence.  We can write it down, usually based on published standards
documents.

That's more true of the functional ABI than it is of the function
prologue sequences.  Which one of those two mostly works once we get it
implemented, and which one is an evolving and recurring pain that we're
contemplating entirely new approaches to? :-)  And that doesn't even
begin to handle debugging non-GCC-generated code.

The more implementation-specific knowledge we have, the less robust we
are.

> If we can find one, and if it is not fragile, then I agree 110%.

I think that single-stepping out of longjmp will not be fragile.  It
may be hard to implement, but it should be straightforward in
principle; it's only going to be hard because of the existing mess
in infrun.c.

Anyway, that's my two cents.  I don't have time to actually implement
it right now, which is why I wanted to mention it on the mailing list;
so that either someone else will look at it, or I will find the message
again later when I can do it myself.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 12/24/05, Eli Zaretskii <eliz@gnu.org> wrote:
> I also don't see any significant difference between dependencies on
> intimate details of the runtime library and the details of the ABI,
> like function prologue emitted by GCC.  We depend on that in lots of
> places.

Like fork and malloc, the ABI is a published, documented interface.  I
think it's all right to depend on that.

The details of the function prologues emitted by GCC are not a public
interface, and are, again, a constant source of troubles.

I think it's okay to depend on the first, and I think it's a shame we
depend on the latter (even as I try to design mechanisms that will
help make that dependence less troublesome).

Re: Stepping over longjmp presumably broken for glibc

[Eli Zaretskii]

> Date: Sun, 25 Dec 2005 20:06:42 -0800
> From: Jim Blandy <jimb@red-bean.com>
> Cc: gdb@sourceware.org
> 
> On 12/24/05, Eli Zaretskii <eliz@gnu.org> wrote:
> > I also don't see any significant difference between dependencies on
> > intimate details of the runtime library and the details of the ABI,
> > like function prologue emitted by GCC.  We depend on that in lots of
> > places.
> 
> Like fork and malloc, the ABI is a published, documented interface.  I
> think it's all right to depend on that.

It's not that simple, you know: we allow the architecture to specify
an arbitrary name for the malloc function.  I also remember that we
sometimes look for several known names of a function, but I cannot for
the moment find it in the sources.  I did find proc-events.c, which
seems to list all the syscall names on a certain platform.

> The details of the function prologues emitted by GCC are not a public
> interface, and are, again, a constant source of troubles.

How do other debuggers do things for which we need the function
prologues?  If they also have intimate knowledge of the prologues,
then I think it's okay for us as well.

My point was that we already depend on all kinds of ad-hoc knowledge
of the ABI and the runtime, so adding one more dependency would not
hurt too much, although I'd applaud to changes to do that without any
such dependencies.

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 12/25/05, Eli Zaretskii <eliz@gnu.org> wrote:
> My point was that we already depend on all kinds of ad-hoc knowledge
> of the ABI and the runtime, so adding one more dependency would not
> hurt too much, although I'd applaud to changes to do that without any
> such dependencies.

I think Daniel's intent was to solicit ideas, indicating what sort of
ideas he prefers.  It sounds like you agree with his preference, but
don't have any qualifying ideas.  Daniel's posts don't give me the
impression that he minds using ad-hoc information when there's no
alternative.

Here's my (non-qualifying because it relies on help from the runtime)
idea: can't we use Dwarf CFI here?  That is, treat longjmp as a weird
function whose CFI indicates that it unwinds to the setjmp.  The
DW_CFA_val_expression operator, new in the released Dwarf 3 spec,
allows CFI to use an arbitrary expression to compute the saved value
of the register; we can apply that to the return address column just
as well as anything else.  In the case Daniel described, the
expression would use DW_OP_xor (probably the first use ever of that
opcode!).

Dwarf 3 Draft 9.7, Section 6.4.1:
...
The register rules are:
...
val_expression(E) The previous value of this register is the value
produced by executing the DWARF expression E.

Section 6.4.2:
...
21. DW_CFA_val_expression

    The DW_CFA_val_expression instruction takes two operands: an
unsigned LEB128 value representing a register number, and a
DW_FORM_block value representing a DWARF expression. The required
action is to change the rule for the register indicated by the
register number to be a val_expression(E) rule where E is the DWARF
expression. That is, the DWARF expression computes the value of the
given register. The value of the CFA is pushed on the DWARF evaluation
stack prior to execution of the DWARF expression.

The DW_OP_call2, DW_OP_call4, DW_OP_call_ref and
DW_OP_push_object_address DWARF operators (see Section 2.5.1) cannot
be used in such a DWARF expression.

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Mon, Dec 26, 2005 at 08:24:30PM -0800, Jim Blandy wrote:
> Here's my (non-qualifying because it relies on help from the runtime)
> idea: can't we use Dwarf CFI here?  That is, treat longjmp as a weird
> function whose CFI indicates that it unwinds to the setjmp.  The
> DW_CFA_val_expression operator, new in the released Dwarf 3 spec,
> allows CFI to use an arbitrary expression to compute the saved value
> of the register; we can apply that to the return address column just
> as well as anything else.  In the case Daniel described, the
> expression would use DW_OP_xor (probably the first use ever of that
> opcode!).

How would you distinguish a longjmp with CFI that returns to caller
from a longjmp with CFI that returns to setjmp?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Mark Kettenis]

> Date: Thu, 29 Dec 2005 21:38:31 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Mon, Dec 26, 2005 at 08:24:30PM -0800, Jim Blandy wrote:
> > Here's my (non-qualifying because it relies on help from the runtime)
> > idea: can't we use Dwarf CFI here?  That is, treat longjmp as a weird
> > function whose CFI indicates that it unwinds to the setjmp.  The
> > DW_CFA_val_expression operator, new in the released Dwarf 3 spec,
> > allows CFI to use an arbitrary expression to compute the saved value
> > of the register; we can apply that to the return address column just
> > as well as anything else.  In the case Daniel described, the
> > expression would use DW_OP_xor (probably the first use ever of that
> > opcode!).
> 
> How would you distinguish a longjmp with CFI that returns to caller
> from a longjmp with CFI that returns to setjmp?

Huh?  longjmp() always returns to a context saved by a setjmp().

Mark

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Dec 30, 2005 at 10:32:11AM +0100, Mark Kettenis wrote:
> > Date: Thu, 29 Dec 2005 21:38:31 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > On Mon, Dec 26, 2005 at 08:24:30PM -0800, Jim Blandy wrote:
> > > Here's my (non-qualifying because it relies on help from the runtime)
> > > idea: can't we use Dwarf CFI here?  That is, treat longjmp as a weird
> > > function whose CFI indicates that it unwinds to the setjmp.  The
> > > DW_CFA_val_expression operator, new in the released Dwarf 3 spec,
> > > allows CFI to use an arbitrary expression to compute the saved value
> > > of the register; we can apply that to the return address column just
> > > as well as anything else.  In the case Daniel described, the
> > > expression would use DW_OP_xor (probably the first use ever of that
> > > opcode!).
> > 
> > How would you distinguish a longjmp with CFI that returns to caller
> > from a longjmp with CFI that returns to setjmp?
> 
> Huh?  longjmp() always returns to a context saved by a setjmp().

That's not what I meant - I meant between a longjmp with "normal"
unwind information, or with Jim's proposed "magic" unwind information
that returned to the setjmp target.  There's got to be at least one of
the former out there somewhere...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 12/30/05, Daniel Jacobowitz <drow@false.org> wrote:
> That's not what I meant - I meant between a longjmp with "normal"
> unwind information, or with Jim's proposed "magic" unwind information
> that returned to the setjmp target.  There's got to be at least one of
> the former out there somewhere...

Why do you need to?  If I'm thinking this through right, once longjmp
is annotated this way, GDB has no further work to do.  The bug is
"fixed", just not in GDB.

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Sun, Jan 01, 2006 at 09:25:14PM -0800, Jim Blandy wrote:
> On 12/30/05, Daniel Jacobowitz <drow@false.org> wrote:
> > That's not what I meant - I meant between a longjmp with "normal"
> > unwind information, or with Jim's proposed "magic" unwind information
> > that returned to the setjmp target.  There's got to be at least one of
> > the former out there somewhere...
> 
> Why do you need to?  If I'm thinking this through right, once longjmp
> is annotated this way, GDB has no further work to do.  The bug is
> "fixed", just not in GDB.

I don't know about you, but I'd be pretty disturbed if "break longjmp;
continue; backtrace; up; list" showed me a setjmp instead of a longjmp.

On the other hand, I see that the glibc x86_64 longjmp implementation
already has CFI which backtraces through the jmp_buf.  Yuck.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 1/6/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Jan 01, 2006 at 09:25:14PM -0800, Jim Blandy wrote:
> > On 12/30/05, Daniel Jacobowitz <drow@false.org> wrote:
> > > That's not what I meant - I meant between a longjmp with "normal"
> > > unwind information, or with Jim's proposed "magic" unwind information
> > > that returned to the setjmp target.  There's got to be at least one of
> > > the former out there somewhere...
> >
> > Why do you need to?  If I'm thinking this through right, once longjmp
> > is annotated this way, GDB has no further work to do.  The bug is
> > "fixed", just not in GDB.
>
> I don't know about you, but I'd be pretty disturbed if "break longjmp;
> continue; backtrace; up; list" showed me a setjmp instead of a longjmp.

The original topic of this thread was stepping through longjmp
instruction by instruction.  At some point, longjmp will inevitably
have disturbed the state of the processor enough that you can't unwind
back to longjmp's caller.  At that point, it makes more sense for the
'calling' frame to be the setjmp than anything else.  Until that
point, you can have the CFI unwind to the longjmp if you prefer.

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Jan 06, 2006 at 12:28:47PM -0800, Jim Blandy wrote:
> On 1/6/06, Daniel Jacobowitz <drow@false.org> wrote:
> > On Sun, Jan 01, 2006 at 09:25:14PM -0800, Jim Blandy wrote:
> > > On 12/30/05, Daniel Jacobowitz <drow@false.org> wrote:
> > > > That's not what I meant - I meant between a longjmp with "normal"
> > > > unwind information, or with Jim's proposed "magic" unwind information
> > > > that returned to the setjmp target.  There's got to be at least one of
> > > > the former out there somewhere...
> > >
> > > Why do you need to?  If I'm thinking this through right, once longjmp
> > > is annotated this way, GDB has no further work to do.  The bug is
> > > "fixed", just not in GDB.
> >
> > I don't know about you, but I'd be pretty disturbed if "break longjmp;
> > continue; backtrace; up; list" showed me a setjmp instead of a longjmp.
> 
> The original topic of this thread was stepping through longjmp
> instruction by instruction.  At some point, longjmp will inevitably
> have disturbed the state of the processor enough that you can't unwind
> back to longjmp's caller.  At that point, it makes more sense for the
> 'calling' frame to be the setjmp than anything else.  Until that
> point, you can have the CFI unwind to the longjmp if you prefer.

But how can GDB reliably use this?  We don't know whether the unwind
information returns to longjmp's call site or setjmp's.  And we might
have to single step a bit to get to the point where it returns to the
setjmp.  So as far as I'm concerned we might as well just single step
until we're out of longjmp.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy]

On 1/6/06, Daniel Jacobowitz <drow@false.org> wrote:
> > The original topic of this thread was stepping through longjmp
> > instruction by instruction.  At some point, longjmp will inevitably
> > have disturbed the state of the processor enough that you can't unwind
> > back to longjmp's caller.  At that point, it makes more sense for the
> > 'calling' frame to be the setjmp than anything else.  Until that
> > point, you can have the CFI unwind to the longjmp if you prefer.
>
> But how can GDB reliably use this?  We don't know whether the unwind
> information returns to longjmp's call site or setjmp's.  And we might
> have to single step a bit to get to the point where it returns to the
> setjmp.  So as far as I'm concerned we might as well just single step
> until we're out of longjmp.

Sorry --- I'm losing track of the original goal here.  Forget I wrote
that.  I think stepping through longjmp is fine.

Independently, I'm excited about having groovy CFI for longjmp.

Re: Stepping over longjmp presumably broken for glibc

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on 
> 	elgar.sibelius.xs4all.nl
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no 
> 	version=3.1.0
> Date: Fri, 6 Jan 2006 15:36:42 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sourceware.org
> Mail-Followup-To: Jim Blandy <jimb@red-bean.com>,
> 	Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sourceware.org
> Content-Disposition: inline
> X-XS4ALL-DNSBL-Checked: mxdrop28.xs4all.nl checked 66.93.172.17 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0 () 
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> X-UIDL: 1136579810._smtp.mxdrop28.60854,S=3285
> 
> On Fri, Jan 06, 2006 at 12:28:47PM -0800, Jim Blandy wrote:
> > The original topic of this thread was stepping through longjmp
> > instruction by instruction.  At some point, longjmp will inevitably
> > have disturbed the state of the processor enough that you can't unwind
> > back to longjmp's caller.  At that point, it makes more sense for the
> > 'calling' frame to be the setjmp than anything else.  Until that
> > point, you can have the CFI unwind to the longjmp if you prefer.
> 
> But how can GDB reliably use this?  We don't know whether the unwind
> information returns to longjmp's call site or setjmp's.

But we can check whether it returns to setjmp or not.

Mark

Re: Stepping over longjmp presumably broken for glibc

[Daniel Jacobowitz]

On Fri, Jan 06, 2006 at 10:26:29PM +0100, Mark Kettenis wrote:
> But we can check whether it returns to setjmp or not.

How?  It won't return to "setjmp", but to setjmp's call site.

-- 
Daniel Jacobowitz
CodeSourcery