Re: longjmp handling vs. glibc LD_POINTER_GUARD problems

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 14, 2008 at 08:00:18PM +0200, Ulrich Weigand wrote:
> To implement implement get_longjmp_target I'd have to retrieve
> that guard value and demangle the pointers.  This is of course
> possible in principle -- but this assumes that the details of
> where to find the guard value (typically somewhere in the
> thread control block header) remain fixed across glibc versions.
> I'm not sure we can actually rely on that.  I couldn't find any
> exported glibc mechanism to retrieve this value in a supported
> way either ...

Indeed, there isn't such a mechanism, and the mangling algorithm has
changed at least once in the past.

> I'm now wondering how we should handle this.  Should be 
> implement an ad-hoc solution to retrieve the guard, which
> may break in the future if glibc changes?  Should we require
> use of LD_POINTER_GUARD=0 (which switches off the pointer
> guard mechanism) to enable debugging?  Am I overlooking some
> defined interface to get at the value?
> 
> Why are we using the get_longjmp_target mechanism instead of
> just stepping through longjmp until we see where we come out?

Bingo.  I discussed this with Pedro, in followups to one of his nine
patches... ah, here it is.

http://sourceware.org/ml/gdb-patches/2008-04/msg00252.html

And stepping on platforms that don't provide a fetch routine, plus not
providing fetch routines on platforms which mangle the pointer, is my
best idea so far.  Maybe dropping the fetcher entirely?  Will that be
too slow?

-- 
Daniel Jacobowitz
CodeSourcery