This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFA/BFD] Fix 2 problems with HP/UX core files...


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


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