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: Pedro Alves <pedro at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org, Daniel Jacobowitz <dan at codesourcery dot com>
- Date: Wed, 21 May 2008 20:38:02 +0100
- Subject: Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems
- References: <200805211920.m4LJKJXS016101@d12av02.megacenter.de.ibm.com>
A Wednesday 21 May 2008 20:20:19, Ulrich Weigand wrote:
> 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 ...
I had forgotten to that the longjmp breakpoints are only inserted
when there's a gdbarch_get_longjmp_target implementation, and none
of those target implements it ...
If you're willing, could you try changing
breakpoint.c:set_longjmp_breakpoint like so?
void
set_longjmp_breakpoint (void)
{
struct breakpoint *b;
- if (gdbarch_get_longjmp_target_p (current_gdbarch))
- {
create_longjmp_breakpoint ("longjmp");
create_longjmp_breakpoint ("_longjmp");
create_longjmp_breakpoint ("siglongjmp");
create_longjmp_breakpoint ("_siglongjmp");
- }
}
>
> 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?
Hmm, coroutines and different stacks, ... I had mentioned in the
other threads it wouldn't work on those cases. ;-)
OK. That may work too. I'll give it a try.
--
Pedro Alves