longjmp handling vs. glibc LD_POINTER_GUARD problems

["Ulrich Weigand" <uweigand@de.ibm.com>]

Hello,

since the recent "stepping over longjmp" patches went in,
I'm seeing test suite failures in longjmp.exp on s390, spu,
and powerpc -- because none of those platforms actually
implement get_longjmp_target.

While I was trying to implement the missing routines, I ran
into a problem: on current glibcs, the return address as
stored in the jmp_buf is actually "mangled", i.e. XORed
with a magic "pointer guard" value.  This is apparently
intended to provide some protection against buffer overflow
attacks ...

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 ...

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?

I'd appreciate your thoughts on this ...

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com