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

[Pedro Alves <pedro@codesourcery.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