This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: handle new NT_SIGINFO note in gdb


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]