From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: handle new NT_SIGINFO note in gdb
Date: Fri, 02 Nov 2012 19:02:00 -0000 [thread overview]
Message-ID: <509418AC.2060404@redhat.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2012-11-02 19:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <878vanyj3k.fsf__16012.8015945249$1351617533$gmane$org@fleche.redhat.com>
2012-11-01 19:01 ` Tom Tromey
2012-11-02 18:21 ` Tom Tromey
2012-11-02 19:02 ` Pedro Alves [this message]
2012-11-02 19:32 ` Tom Tromey
2012-11-05 18:11 ` Pedro Alves
2012-11-08 21:10 ` Tom Tromey
2012-10-30 17:18 Tom Tromey
2012-10-30 18:31 ` Pedro Alves
2012-11-01 1:12 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=509418AC.2060404@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox