From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29725 invoked by alias); 10 Sep 2004 21:14:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29433 invoked from network); 10 Sep 2004 21:14:27 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 10 Sep 2004 21:14:27 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id D156A47D92; Fri, 10 Sep 2004 14:14:23 -0700 (PDT) Date: Fri, 10 Sep 2004 21:14:00 -0000 From: Joel Brobecker To: binutils@sources.redhat.com Cc: gdb-patches@sources.redhat.com Subject: [RFA] Fix 2 problems with HP/UX core files... Message-ID: <20040910211423.GN5843@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="8X7/QrJGcKSMr1RN" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00174.txt.bz2 --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 2986 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 * 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/" 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 --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hpux-core.c.diff" Content-length: 2548 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 --8X7/QrJGcKSMr1RN--