This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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]

[RFA] Fix 2 problems with HP/UX core files...


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: hpux-core.c.diff
Description: Text document


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