A Saturday 17 May 2008 03:17:17, Pedro Alves wrote:
> A Wednesday 14 May 2008 19:16:23, Pedro Alves wrote:
> > A Wednesday 14 May 2008 19:00:18, Ulrich Weigand wrote:
> > > Why are we using the get_longjmp_target mechanism instead of
> > > just stepping through longjmp until we see where we come out?
> >
> > You tell me.  :-)  I had assumed there was a reason.  Perhaps
> > to support longjumping to a different stack, but that's hardly
> > a portable and frequent use case.  This seems to be the path
> > to go.
>
> Alright, here is a quick hack at it.  If this is the path to go,
> we can remove a bunch of gdbarch_get_longjmp_target implementations,
> and the code around longjmp_resume breakpoints.
>
> The patch implements the "keep stepping if going through a longjmp",
> and also, if landing somewhere inner than the current step-resume, we
> keep stepping, which is an alternative and simple implementation
> of what I proposed here:
>
> http://sourceware.org/ml/gdb-patches/2008-04/msg00162.html
>
> Tested on x86_64-unknown-linux-gnu.  The longjmp.exp passes all ok,
> and we become immune to pointer mangling.
>
> I've also simplified a bit the test, removing stuff that wasn't
> adding any value.
>


> One thing, why do I need to call get_frame_type before calling
> frame_unwind_id (first thing after frame cache invalidation)?  If I
> don't do that, I hit this gdb_assert:

Since this is now fixed, :
 http://sourceware.org/ml/gdb-patches/2008-05/msg00605.html

... 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?

-- 
Pedro Alves