stepping over longjmp

stepping over longjmp

[Nick Roberts]

With current CVS GDB and Fedora Core 5 i686 i386 GNU/Linux (2.6.17-1.2157 but
also 2.6.15) when I try to step over longjmp (using next) I get the following
error:

  Warning:
  Cannot insert breakpoint -59.
  Error accessing memory address 0x226092c5: Input/output error.

ISTR that this was also the case with FC4 and have only recently realised that
you can step usefully step over a longjmp call after trying it on Mandrake 9
(2.4.19)

Is this a known kernel problem or a bug in GDB?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: stepping over longjmp

[Daniel Jacobowitz]

On Fri, Aug 04, 2006 at 08:11:32PM +1200, Nick Roberts wrote:
> 
> With current CVS GDB and Fedora Core 5 i686 i386 GNU/Linux (2.6.17-1.2157 but
> also 2.6.15) when I try to step over longjmp (using next) I get the following
> error:
> 
>   Warning:
>   Cannot insert breakpoint -59.
>   Error accessing memory address 0x226092c5: Input/output error.
> 
> ISTR that this was also the case with FC4 and have only recently realised that
> you can step usefully step over a longjmp call after trying it on Mandrake 9
> (2.4.19)
> 
> Is this a known kernel problem or a bug in GDB?

Has nothing to do with the kernel.  I imagine that this is the problem
I discussed on this list a while ago, CC'd to libc-alpha; glibc now
uses a canary in the jmp_buf which GDB has no way to access.

Does export LD_POINTER_GUARD=0 make a difference?

-- 
Daniel Jacobowitz
CodeSourcery

Re: stepping over longjmp

[Nick Roberts]

 > > Is this a known kernel problem or a bug in GDB?
 > 
 > Has nothing to do with the kernel.  I imagine that this is the problem
 > I discussed on this list a while ago, CC'd to libc-alpha; glibc now
 > uses a canary in the jmp_buf which GDB has no way to access.

Sorry, I should have searched the archives first.

 > Does export LD_POINTER_GUARD=0 make a difference?

No.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: stepping over longjmp

[Daniel Jacobowitz]

On Sat, Aug 05, 2006 at 10:19:13AM +1200, Nick Roberts wrote:
>  > > Is this a known kernel problem or a bug in GDB?
>  > 
>  > Has nothing to do with the kernel.  I imagine that this is the problem
>  > I discussed on this list a while ago, CC'd to libc-alpha; glibc now
>  > uses a canary in the jmp_buf which GDB has no way to access.
> 
> Sorry, I should have searched the archives first.
> 
>  > Does export LD_POINTER_GUARD=0 make a difference?
> 
> No.

Hmm, then it must be something else.

-- 
Daniel Jacobowitz
CodeSourcery

Re: stepping over longjmp

[Nick Roberts]

 > >  > Does export LD_POINTER_GUARD=0 make a difference?
 > > 
 > > No.
 > 
 > Hmm, then it must be something else.

Actually, it does work if it's set for both compilation and execution.  I also
updated to 2.4-8 (from 2.4-4).  I don't know if that was necessary but on the
Internet I saw:

> You can disable the encryption using the LD_POINTER_GUARD environment
> variable.  Unfortunately the glibc version so far in FC5 has a little
> bug.  The next update will allow you to specify LD_POINTER_GUARD=0.
>
> But this is really the wrong solution.  The program should be  
> rewritten
> to use __builtin_frame_address (see the gcc manual).
>
> -- Ulrich Drepper

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: stepping over longjmp

[Daniel Jacobowitz]

On Sat, Aug 05, 2006 at 02:08:29PM +1200, Nick Roberts wrote:
>  > >  > Does export LD_POINTER_GUARD=0 make a difference?
>  > > 
>  > > No.
>  > 
>  > Hmm, then it must be something else.
> 
> Actually, it does work if it's set for both compilation and execution.  I also
> updated to 2.4-8 (from 2.4-4).  I don't know if that was necessary but on the
> Internet I saw:

It shouldn't make any difference at compilation, FWIW.

-- 
Daniel Jacobowitz
CodeSourcery

Re: stepping over longjmp

[Nick Roberts]

 > > Actually, it does work if it's set for both compilation and execution.  I
 > > also updated to 2.4-8 (from 2.4-4).  I don't know if that was necessary
 > > but on the Internet I saw:
 > 
 > It shouldn't make any difference at compilation, FWIW.

Maybe LD_POINTER_GUARD wasn't set at my first attempt then (or maybe I hadn't
updated), but if it's a security feature then I'm a bit surprised you can
override it just by setting an environment variable (if it was needed/used for
compilation then that would provide a choice over the level of security).

As a side note to Eli, perhaps we should mention it in the Emacs DEBUG file.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: stepping over longjmp

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 5 Aug 2006 18:08:36 +1200
> Cc: gdb@sources.redhat.com
> 
> As a side note to Eli, perhaps we should mention it in the Emacs DEBUG file.

It's a good idea, yes.

Re: stepping over longjmp

[Mark Kettenis]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 5 Aug 2006 14:08:29 +1200
> 
>  > >  > Does export LD_POINTER_GUARD=0 make a difference?
>  > > 
>  > > No.
>  > 
>  > Hmm, then it must be something else.
> 
> Actually, it does work if it's set for both compilation and execution.  I also
> updated to 2.4-8 (from 2.4-4).  I don't know if that was necessary but on the
> Internet I saw:
> 
> > You can disable the encryption using the LD_POINTER_GUARD environment
> > variable.  Unfortunately the glibc version so far in FC5 has a little
> > bug.  The next update will allow you to specify LD_POINTER_GUARD=0.
> >
> > But this is really the wrong solution.  The program should be  
> > rewritten
> > to use __builtin_frame_address (see the gcc manual).
> >
> > -- Ulrich Drepper

Unfortunately Ulrich's argument doesn't hold for GDB.  But if we can
get at the "cookie" that's used to encrypt the addess, it should be
possible to undo the encryption.  Lookes like the cookie is somewhere
in thread local storage.  I'll see if I can come up with a way to
access it.

Mark

Re: stepping over longjmp

[Daniel Jacobowitz]

On Sat, Aug 05, 2006 at 02:39:58PM +0200, Mark Kettenis wrote:
> Unfortunately Ulrich's argument doesn't hold for GDB.  But if we can
> get at the "cookie" that's used to encrypt the addess, it should be
> possible to undo the encryption.  Lookes like the cookie is somewhere
> in thread local storage.  I'll see if I can come up with a way to
> access it.

It varies from platform to platform.  There's actually two cookies (one
for "pointers" and one for the GCC stack protection), and while the
stack protection pointer is an ABI, the pointer protection cookie is
considered glibc internal and might move around.  And what's protected
with it also varies from architecture to architecture, and version to
version.

I'm hoping that you can make an educated guess about where to find it
anyway :-)  Alternatively, maybe they'd be open to a debugging
interface.

-- 
Daniel Jacobowitz
CodeSourcery