public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [RFA] Fix 2 problems with HP/UX core files...
@ 2004-09-10 21:14 Joel Brobecker
  2004-09-12 16:40 ` [RFA/BFD] " Joel Brobecker
  0 siblings, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2004-09-10 21:14 UTC (permalink / raw)
  To: binutils; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

Hello,

We noticed two problems in GDB relative to core file handling on HP/UX,
and we think they should be corrected in GDB.

The first problem is that BFD only sees 1 thread section in the core
file. All the other sections after that one are ignored. This is because
there is a small bug in the code processing PROC sections: We read
the section to extract the proc info data, and then seek back in
the core file to the begining of the section:

        if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)

Unfortunately, core_header.len is an unsigned int (4 bytes), while
file_ptr is a long_int (8 bytes). The promotion to file_ptr needs
to be done first, before the negation is made. Instead, we end up
with a very large value in the call to bfd_seek, so we end up moving
forward in the file, instead of going back to the begining of the
section. Fixed by the following change:

-            if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)
+            if (bfd_seek (abfd, -((file_ptr) core_header.len), SEEK_CUR) != 0)

The second problem is a bit more specific to a certain kind of core
files. We have a multi-threaded program that is running. And then
an external program attaches itself to that program (exactly like
a debugger), and issues a TT_CORE ttrace system call. This causes
a core file to be generated.

But unfortunately, the signal value in all PROC sections is set
to -1. Which means that BFD doesn't select any thread as the active
thread, and ends up not creating any ".reg" section.

The consequence at the user level for GDB is that GDB complains
that it can not find the general purpose registers, and leaves
all registers unset.

So what I did was check after reading the core file that we did
create a ".reg" section. If not, then I pick one thread section
at random (the first one I find), and use that one to create the
associated ".reg" section.

2004-09-10  Joel Brobecker  <brobecker@gnat.com>

        * hpux-core.c (thread_section_p): New function.
        (hpux_core_core_file_p): Fix computation of offset in call
        to bfd_seek. Create a ".reg" section from an arbitrary
        ".reg/<id>" section if none was created after having read
        all sections.

Tested on HP/UX 11.00 using GDB's testsuite. Fixes the following
tests:

+------------+------------+----------------------------------------------------+
|       FAIL | PASS       | corefile.exp: print coremaker_data                 |
|       FAIL | PASS       | corefile.exp: print coremaker_bss                  |
|       FAIL | PASS       | corefile.exp: accessing original mmap data in  ... |
|            |            | ... core file                                      |
|       FAIL | PASS       | corefile.exp: accessing mmapped data in core f ... |
|            |            | ... ile (mapping address not found in core file)   |
+------------+------------+----------------------------------------------------+

OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: hpux-core.c.diff --]
[-- Type: text/plain, Size: 2548 bytes --]

Index: hpux-core.c
===================================================================
RCS file: /cvs/src/src/bfd/hpux-core.c,v
retrieving revision 1.13
diff -u -p -r1.13 hpux-core.c
--- hpux-core.c	24 Jun 2004 04:46:23 -0000	1.13
+++ hpux-core.c	9 Sep 2004 21:18:40 -0000
@@ -145,6 +145,17 @@ make_bfd_asection (abfd, name, flags, si
   return asect;
 }
 
+/* Return true if the given core file section corresponds to a thread,
+   based on its name.  */
+
+static int
+thread_section_p (bfd *abfd ATTRIBUTE_UNUSED,
+                  asection *sect,
+                  void *obj ATTRIBUTE_UNUSED)
+{
+  return (strncmp (bfd_section_name (abfd, sect), ".reg/", 5) == 0);
+}
+
 /* this function builds a bfd target if the file is a corefile.
    It returns null or 0 if it finds out thaat it is not a core file.
    The way it checks this is by looking for allowed 'type' field values.
@@ -207,7 +218,7 @@ hpux_core_core_file_p (abfd)
 
               /* However, we also want to create those sections with the
                  file positioned at the start of the record, it seems. */
-            if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)
+            if (bfd_seek (abfd, -((file_ptr) core_header.len), SEEK_CUR) != 0)
               break;
 
 #if defined(PROC_INFO_HAS_THREAD_ID)
@@ -301,6 +312,29 @@ hpux_core_core_file_p (abfd)
 
   /* OK, we believe you.  You're a core file (sure, sure).  */
 
+  /* On HP/UX, we sometimes encounter core files where none of the threads
+     was found to be the running thread (ie the signal was set to -1 for
+     all threads).  This happens when the program was aborted externally
+     via a TT_CORE ttrace system call.  In that case, we just pick one
+     thread at random to be the active thread.  */
+  if (core_kernel_thread_id (abfd) != 0
+      && bfd_get_section_by_name (abfd, ".reg") == NULL)
+    {
+      asection *asect = bfd_sections_find_if (abfd, thread_section_p, NULL);
+      asection *reg_sect;
+
+      if (asect != NULL)
+        {
+          reg_sect = make_bfd_asection (abfd, ".reg", asect->flags,
+                                        asect->size, asect->vma,
+                                        asect->alignment_power);
+          if (reg_sect == NULL)
+            goto fail;
+
+          reg_sect->filepos = asect->filepos;
+        }
+    }
+
   /* Were there sections of unknown type?  If so, yet there were
      at least some complete sections of known type, then, issue
      a warning.  Possibly the core file was generated on a version

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA/BFD] Fix 2 problems with HP/UX core files...
  2004-09-10 21:14 [RFA] Fix 2 problems with HP/UX core files Joel Brobecker
@ 2004-09-12 16:40 ` Joel Brobecker
  2004-09-12 23:13   ` Alan Modra
  0 siblings, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2004-09-12 16:40 UTC (permalink / raw)
  To: binutils; +Cc: gdb-patches

Hello again,

Andrew noticed a big typo in my message that makes it really confusing:

> We noticed two problems in GDB relative to core file handling on HP/UX,
> and we think they should be corrected in GDB.
                                           ^^^ *BFD* !!!

The first problem is that BFD only sees 1 thread section in the core
file. All the other sections after that one are ignored. This is because
there is a small bug in the code processing PROC sections: We read
the section to extract the proc info data, and then seek back in
the core file to the begining of the section:

        if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)

Unfortunately, core_header.len is an unsigned int (4 bytes), while
file_ptr is a long_int (8 bytes). The promotion to file_ptr needs
to be done first, before the negation is made. Instead, we end up
with a very large value in the call to bfd_seek, so we end up moving
forward in the file, instead of going back to the begining of the
section. Fixed by the following change:

-            if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)
+            if (bfd_seek (abfd, -((file_ptr) core_header.len), SEEK_CUR) != 0)

The second problem is a bit more specific to a certain kind of core
files. We have a multi-threaded program that is running. And then
an external program attaches itself to that program (exactly like
a debugger), and issues a TT_CORE ttrace system call. This causes
a core file to be generated.

But unfortunately, the signal value in all PROC sections is set
to -1. Which means that BFD doesn't select any thread as the active
thread, and ends up not creating any ".reg" section.

The consequence at the user level for GDB is that GDB complains
that it can not find the general purpose registers, and leaves
all registers unset.

So what I did was check after reading the core file that we did
create a ".reg" section. If not, then I pick one thread section
at random (the first one I find), and use that one to create the
associated ".reg" section.

2004-09-10  Joel Brobecker  <brobecker@gnat.com>

        * hpux-core.c (thread_section_p): New function.
        (hpux_core_core_file_p): Fix computation of offset in call
        to bfd_seek. Create a ".reg" section from an arbitrary
        ".reg/<id>" section if none was created after having read
        all sections.

Tested on HP/UX 11.00 using GDB's testsuite. Fixes the following
tests:

+------------+------------+----------------------------------------------------+
|       FAIL | PASS       | corefile.exp: print coremaker_data                 |
|       FAIL | PASS       | corefile.exp: print coremaker_bss                  |
|       FAIL | PASS       | corefile.exp: accessing original mmap data in  ... |
|            |            | ... core file                                      |
|       FAIL | PASS       | corefile.exp: accessing mmapped data in core f ... |
|            |            | ... ile (mapping address not found in core file)   |
+------------+------------+----------------------------------------------------+

OK to apply?

Thanks,
-- 
Joel

Index: hpux-core.c
===================================================================
RCS file: /cvs/src/src/bfd/hpux-core.c,v
retrieving revision 1.13
diff -u -p -r1.13 hpux-core.c
--- hpux-core.c	24 Jun 2004 04:46:23 -0000	1.13
+++ hpux-core.c	9 Sep 2004 21:18:40 -0000
@@ -145,6 +145,17 @@ make_bfd_asection (abfd, name, flags, si
   return asect;
 }
 
+/* Return true if the given core file section corresponds to a thread,
+   based on its name.  */
+
+static int
+thread_section_p (bfd *abfd ATTRIBUTE_UNUSED,
+                  asection *sect,
+                  void *obj ATTRIBUTE_UNUSED)
+{
+  return (strncmp (bfd_section_name (abfd, sect), ".reg/", 5) == 0);
+}
+
 /* this function builds a bfd target if the file is a corefile.
    It returns null or 0 if it finds out thaat it is not a core file.
    The way it checks this is by looking for allowed 'type' field values.
@@ -207,7 +218,7 @@ hpux_core_core_file_p (abfd)
 
               /* However, we also want to create those sections with the
                  file positioned at the start of the record, it seems. */
-            if (bfd_seek (abfd, (file_ptr) -core_header.len, SEEK_CUR) != 0)
+            if (bfd_seek (abfd, -((file_ptr) core_header.len), SEEK_CUR) != 0)
               break;
 
 #if defined(PROC_INFO_HAS_THREAD_ID)
@@ -301,6 +312,29 @@ hpux_core_core_file_p (abfd)
 
   /* OK, we believe you.  You're a core file (sure, sure).  */
 
+  /* On HP/UX, we sometimes encounter core files where none of the threads
+     was found to be the running thread (ie the signal was set to -1 for
+     all threads).  This happens when the program was aborted externally
+     via a TT_CORE ttrace system call.  In that case, we just pick one
+     thread at random to be the active thread.  */
+  if (core_kernel_thread_id (abfd) != 0
+      && bfd_get_section_by_name (abfd, ".reg") == NULL)
+    {
+      asection *asect = bfd_sections_find_if (abfd, thread_section_p, NULL);
+      asection *reg_sect;
+
+      if (asect != NULL)
+        {
+          reg_sect = make_bfd_asection (abfd, ".reg", asect->flags,
+                                        asect->size, asect->vma,
+                                        asect->alignment_power);
+          if (reg_sect == NULL)
+            goto fail;
+
+          reg_sect->filepos = asect->filepos;
+        }
+    }
+
   /* Were there sections of unknown type?  If so, yet there were
      at least some complete sections of known type, then, issue
      a warning.  Possibly the core file was generated on a version

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA/BFD] Fix 2 problems with HP/UX core files...
  2004-09-12 16:40 ` [RFA/BFD] " Joel Brobecker
@ 2004-09-12 23:13   ` Alan Modra
  2004-09-13  3:51     ` Joel Brobecker
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2004-09-12 23:13 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: binutils, gdb-patches

On Sun, Sep 12, 2004 at 09:40:26AM -0700, Joel Brobecker wrote:
>         * hpux-core.c (thread_section_p): New function.
>         (hpux_core_core_file_p): Fix computation of offset in call
>         to bfd_seek. Create a ".reg" section from an arbitrary
>         ".reg/<id>" section if none was created after having read
>         all sections.

This is OK.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFA/BFD] Fix 2 problems with HP/UX core files...
  2004-09-12 23:13   ` Alan Modra
@ 2004-09-13  3:51     ` Joel Brobecker
  0 siblings, 0 replies; 4+ messages in thread
From: Joel Brobecker @ 2004-09-13  3:51 UTC (permalink / raw)
  To: binutils, gdb-patches

> On Sun, Sep 12, 2004 at 09:40:26AM -0700, Joel Brobecker wrote:
> >         * hpux-core.c (thread_section_p): New function.
> >         (hpux_core_core_file_p): Fix computation of offset in call
> >         to bfd_seek. Create a ".reg" section from an arbitrary
> >         ".reg/<id>" section if none was created after having read
> >         all sections.
> 
> This is OK.

Thank you! checked in.

-- 
Joel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-09-13  3:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-10 21:14 [RFA] Fix 2 problems with HP/UX core files Joel Brobecker
2004-09-12 16:40 ` [RFA/BFD] " Joel Brobecker
2004-09-12 23:13   ` Alan Modra
2004-09-13  3:51     ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).