Re: [PATCH] add a bfd interface to get at a core file's PID

[Pedro Alves <pedro at codesourcery dot com>]

On Saturday 14 August 2010 19:28:24, Pedro Alves wrote:
> Hi all,
> 
> This patch gets rid of the bfd/elf.c:elfcore_make_pid hack, and
> in its place adds an API that GDB can use to query the PID of the
> process that a core dump was generated from (bfd_core_file_pid).
> GDB needs to know this PID in order to be able to support
> thread_db/pthread debugging on core files.
> 
> The current elfcore_make_pid hack is a nop on most targets, since
> they don't fill in the elf_tdata(bfd)->core_lwpid field, only the
> core_pid field.  Currently, on most targets, since GDB can't get at
> the core's PID, it fakes one up.  Except on Solaris, where a while ago
> I had added the opposite hack of elfcore_make_pid, thus extracting
> the PID from .reg/NNN section names.  This only worked because
> the solaris note groking routines in bfd do write to the core_lwpid
> field.  But this is all a hack, and I'd prefer not propagating
> it on either bfd or gdb, and instead add a cleaner interface to bfd,
> hence this patch.
> 
> The patch goes through all targets making them write to 
> elf_tdata(bfd)->core_lwpid where it makes sense,
> leaving elf_tdata(bfd)->core_pid for the main process's PID.
> 
> For linux x86/x86_64, I also added the necessary bits to extract
> the main process's PID from the psinfo note, and store it in
> elf_tdata(bfd)->core_pid, thus allowing the new interface to return
> something not zero.  I didn't go look up the offsets into psinfo where
> the pid is stored for all other linux archs.  Someone else interested
> in those archs can do that at any later time --- things will
> keep working as they did until that is done.
> 
> Tested by building both gdb and binutils with --enable-targets=all,
> by running the gdb testsuite on x86_64-linux, manually confirming
> that with a couple of follow up patches I could activate
> libthread_db/pthread debugging on x86_64 and x86 linux, and,
> manually confirming that GDB can still grok core files
> on sparc-solaris, generated by both the kernel or gdb.
> 
> Okay to apply?

Looks like I missed that there are some files that need updating
that are host dependent.  E.g., I needed this to build
an x68-linux, but not on x86_64:

Index: src/bfd/trad-core.c
===================================================================
--- src.orig/bfd/trad-core.c    2010-08-04 19:01:09.000000000 +0100
+++ src/bfd/trad-core.c 2010-08-16 20:03:02.000000000 +0100
@@ -71,6 +71,7 @@ const bfd_target *trad_unix_core_file_p 
 char * trad_unix_core_file_failing_command PARAMS ((bfd *abfd));
 int trad_unix_core_file_failing_signal PARAMS ((bfd *abfd));
 #define trad_unix_core_file_matches_executable_p generic_core_file_matches_executable_p
+#define trad_unix_core_file_pid _bfd_nocore_core_fil
 static void swap_abort PARAMS ((void));
 
 /* Handle 4.2-style (and perhaps also sysV-style) core dump file.  */

Any comments on the idea of the patch before I go hunt for other
files that I may have missed?

-- 
Pedro Alves