Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread).

[Pedro Alves <pedro@codesourcery.com>]

On Monday 16 August 2010 18:38:40, Ulrich Weigand wrote:
> Pedro Alves wrote:
> 
> > Index: src/gdb/testsuite/gdb.threads/threxit-hop-specific.exp
> [snip]
> > +# Set a thread specific breakpoint somewhere the main thread will pass
> > +# by, but make it specific to the thread that is going to exit.  Step
> > +# over the pthread_exit call.  GDB should still be able to step over
> > +# the thread specific breakpoint, and reach the other breakpoint,
> > +# which is not thread specific.
> > +set bpthrline [gdb_get_line_number "set thread specific breakpoint here"]
> > +gdb_test "break $bpthrline thread 2" \
> > +    "Breakpoint .*$srcfile.*$bpthrline.*" \
> > +    "set thread specific breakpoint"
> > +
> > +set bpexitline [gdb_get_line_number "set exit breakpoint here"]
> > +gdb_breakpoint "$bpexitline"
> > +
> > +gdb_test "next" \
> > +    ".*set exit breakpoint here.*" \
> > +    "get passed the thread specific breakpoint"
> 
> I'm seeing failures in this test on an ARM system with debug info
> packages installed for libc / libpthread.  The problem is that
> pthread_exit is implemented in terms of pthread cancellation,
> which under the covers does a longjmp back up to the start_thread
> routine in libpthread.
> 
> Normally, GDB will consider this routine to be assembler code and
> continue stepping until the end.  However, if we actually have
> debug info, GDB will stop stepping here (because start_thread
> is in fact the parent of the application's thread routine), and
> thus the test fails.
> 
> This does look like the correct behaviour under the circumstances,
> which would imply the test case is not quite correct.  Do you
> agree or am I missing something here?  

I agree.

> Any thoughts on how to fix the test?

Replacing the "next" by a "continue" should work.  I've looked over the
original description of the problem this is covering, and, that
would still exercise the problem (which is gdb trying to step
the other (main) thread with inferior_ptid still pointing at
the thread that was being "next"ed, and in the process failing
to remove breakpoints from memory because inferior_ptid pointed
at an inferior thread.

-- 
Pedro Alves