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

Ulrich Weigand
2008-05-21T19:21:23Z

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