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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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?  Any thoughts on how to fix
the test?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com