Re: longjmp handling vs. glibc LD_POINTER_GUARD problems

Daniel Jacobowitz
2008-05-14T18:13:43Z

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