This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: handle new NT_SIGINFO note in gdb
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 02 Nov 2012 19:02:04 +0000
- Subject: Re: RFC: handle new NT_SIGINFO note in gdb
- References: <878vanyj3k.fsf__16012.8015945249$1351617533$gmane$org@fleche.redhat.com> <87d2zxrvuw.fsf@fleche.redhat.com> <87390rq319.fsf@fleche.redhat.com>
Looks mostly good to me. Thanks.
On 11/02/2012 06:21 PM, Tom Tromey wrote:> +gdb_test "thread 1" ".*"
> +# siginfo is available here -- it shows SIGSTOP -- so we test to make
> +# sure that we have a different signal from the SEGV thread.
> +gdb_test "p \$_siginfo.si_signo == $ssi_errno" " = 0" \
> + "test signal in main thread"
I think here should be $ssi_signo, not $ssi_errno.
> + # The signalled thread always shows up as thread 1.
> + gdb_test "thread 2" ".*" "switch threads with core file"
> + gdb_test "p \$_siginfo.si_signo == $ssi_errno" " = 0" \
> + "test signal in main thread with core file"
Ditto.
> + # The signalled thread always shows up as thread 1.
> + gdb_test "thread 2" ".*" "switch threads with core file"
Note this is actually more of an accident than GDB making sure that
always happens. GDB makes no effort to make sure the the signaled thread
is the first dumped thread. GDB's internal thread list is ordered
newer->older, and since thread 2 is the one that crashes, and is
the newest, that thread ends up appearing first in the core, and hence
when gdb loads the core, it ends up as selected thread. If it was
thread 1 that crashed, thread 2 in the running program would
still end up as thread 1 in the core. (It just tried that, with a
pristine mainline).
--
Pedro Alves