[patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems

[Ulrich Weigand]

Pedro Alves wrote:

> ... here's an updated patch.  The tests are the same as before.  Tested on 
> x86_86-unknown-linux-gnu, and confirmed longjmp.exp also passes
> cleanly on x86-pc-linux-gnu.
> 
> What do you think?

Looks like the right way to go for me.   Unfortunately, I doesn't quite
work yet on the platforms I've tried it (s390, s390x, powerpc, powerpc64,
and spu) -- the "next" over 
110           call_longjmp (&env); /* patt2 */
always causes the program to run to its end.  I didn't get the chance yet
to debug this problem ...

Another issue with your patch is the use of frame_id_inner ... I'd rather
get rid of this function instead of adding new uses, because this really
requires that it is possible to compare two stack (frame) addresses 
along a linear order.  This breaks for me in multi-architecture scenarios,
but even on existing targets it may not always work OK (e.g. if signal
handlers run on a different frame, or if the code uses some sort of
user-level threading or coroutine library ...).  Maybe instead of
comparing frame_ids, it would be better to check whether or not a
frame with the given ID still exists in the current backtrace?

Bye,
Ulrich

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