This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: pedro at codesourcery dot com (Pedro Alves)
- Cc: gdb-patches at sourceware dot org, dan at codesourcery dot com (Daniel Jacobowitz)
- Date: Wed, 21 May 2008 21:20:19 +0200 (CEST)
- Subject: Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems
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