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] |
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] |