Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: binutils@sourceware.org
Cc: gdb-patches@sourceware.org
Subject: [RFA] core files: wrong signal number with threaded program on sparc-solaris
Date: Thu, 28 Jan 2010 12:37:00 -0000	[thread overview]
Message-ID: <1264682189-9643-1-git-send-email-brobecker@adacore.com> (raw)

From: brobecke <brobecke@f8352e7e-cb20-0410-8ce7-b5d9e71c585c>

Hello,

We noticed the following problem. Given a threaded program that terminated
because of a SIGABRT (and produced a core file), GDB prints the following
information when loading this core file:

        % gdb crash
        (gdb) core core
        [...]
        Core was generated by `./crash'.
        Program terminated with signal 9, Killed.
                                ^^^^^^^^^^^^^^^^
        #0  0xffffffff7eec9128 in kill () from /lib/64/libc.so.1

The expected behavior is to tell the user that the program terminated
because of a SIGABRT:

        Core was generated by `./crash'.
        Program terminated with signal 6, Aborted.
        #0  0xff2c559c in kill () from /lib/libc.so.1

This issue started appearing after the following change was introduced:

        * bfd.m4 (BFD_HAVE_SYS_PROCFS_TYPE): Define _STRUCTURE_PROC
        before including procfs.h.
        (BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise.
        * configure.in: Added autoconf probe for the pr_fpreg member.
        * configure: Regenerated.
        * config.in: Regenerated.
        * elf.c: Define _STRUCTURE_PROC before including procfs.h.

Basically, instead of using the NT_PRSTATUS notes, we now use the
NT_LWPSTATUS ones.  And what happens in our case is that we have
several such notes - I suspect one per thread.  The first note has
a signal set to 6, whereas the next one has a signal set to 9.

Interestingly, the same is true iw the NT_PRSTATUS notes, and digging
a little further, I found the following code in elfcore_grok_prstatus
(this is the function that handles NT_PRSTATUS notes):

      /* Do not overwrite the core signal if it
         has already been set by another thread.  */
      if (elf_tdata (abfd)->core_signal == 0)
        elf_tdata (abfd)->core_signal = prstat.pr_cursig;

It looks like the same logic should be applied in elfcore_grok_lwpstatus.
This is what this patch does.

bfd/ChangeLog:

        * elf.c (elfcore_grok_lwpstatus): Do not overwrite the core signal
        if it has already been set.

Tested on sparc-solaris by running the GDB testsuite. No regression.
OK to apply?

Thanks,
-- 
Joel

---
 bfd/ChangeLog.GNAT |    5 +++++
 bfd/elf.c          |    5 ++++-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/bfd/ChangeLog.GNAT b/bfd/ChangeLog.GNAT
index ea483ec..93b4e85 100644
--- a/bfd/ChangeLog.GNAT
+++ b/bfd/ChangeLog.GNAT
@@ -1,3 +1,8 @@
+2010-01-28  Joel Brobecker  <brobecker@adacore.com>
+
+	* elf.c (elfcore_grok_lwpstatus): Do not overwrite the core signal
+	if it has already been set.
+
 2010-01-01  Joel Brobecker  <brobecker@adacore.com>
 
 	Revert a local change that was unnecessary.
diff --git a/bfd/elf.c b/bfd/elf.c
index aac3314..19e4695 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -7800,7 +7800,10 @@ elfcore_grok_lwpstatus (bfd *abfd, Elf_Internal_Note *note)
   memcpy (&lwpstat, note->descdata, sizeof (lwpstat));
 
   elf_tdata (abfd)->core_lwpid = lwpstat.pr_lwpid;
-  elf_tdata (abfd)->core_signal = lwpstat.pr_cursig;
+  /* Do not overwrite the core signal if it has already been set by
+     another thread.  */
+  if (elf_tdata (abfd)->core_signal == 0)
+    elf_tdata (abfd)->core_signal = lwpstat.pr_cursig;
 
   /* Make a ".reg/999" section.  */
 
-- 
1.6.3.3


             reply	other threads:[~2010-01-28 12:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-28 12:37 Joel Brobecker [this message]
2010-01-28 21:54 ` Alan Modra
2010-01-29  4:33   ` Joel Brobecker

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=1264682189-9643-1-git-send-email-brobecker@adacore.com \
    --to=brobecker@adacore.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /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