bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core dump (semi) update


From: Roland McGrath
Subject: Re: Core dump (semi) update
Date: Fri, 30 Jan 2004 04:51:27 -0500 (EST)

What bfd reports as sections are synthesized from the note data.  core
files don't really have any sections.  The clearest way to see their
contents is with readelf.  Then you can tell whether the file is wrong, or
if the BFD code that reads it for gdb is wrong.

In the NT_LWPSTATUS note format that we write, the FP registers are always
included in the note along with the general registers.  If the FPU wasn't
used, then we just write zeros (see exec/elfcore.c).  BFD's core-grokking
code fakes .reg and .reg2 sections that are just parts of this one note in
actuality.  From looking at the BFD code, the zero file offsets shown for
the .reg2 fake sections suggest that maybe HAVE_LWPSTATUS_T_PR_FPREG didn't
get defined by the configure test, which I think it should have.  I was
about to suggest you look at your gdb build to see what went wrong.  But
looking at the source, there isn't a configure check for pr_fpreg to go
with the bfd/elf.c code (elfcore_grok_lwpstatus).  That would explain that.
You might try this patch bfd/configure.in:

--- configure.in.~1.142.~                        
+++ configure.in       
@@ -441,6 +441,7 @@ changequote([,])dnl
     BFD_HAVE_SYS_PROCFS_TYPE(lwpxstatus_t)
     BFD_HAVE_SYS_PROCFS_TYPE_MEMBER(lwpstatus_t, pr_context)
     BFD_HAVE_SYS_PROCFS_TYPE_MEMBER(lwpstatus_t, pr_reg)
+    BFD_HAVE_SYS_PROCFS_TYPE_MEMBER(lwpstatus_t, pr_fpreg)
     BFD_HAVE_SYS_PROCFS_TYPE(win32_pstatus_t)
   fi
 fi

If that makes a difference, submit it to <binutils@sources.redhat.com> (or
I can if you want, but you test it).  But anyway, that problem should not
affect anything except gdb's ability to see FP registers.

I suppose we might also consider changing the note format.  I chose the new
Solaris style format because at the time it was the established format I
found that handled multiple threads and seemed to be fairly clean and Sun's
preferred format.  The discovery of this bug in BFD makes me realize that
it is, however, not the format that has been used heavily with gdb.  It's
not even used by BFD on Solaris because all those configure checks come up
false unless you #define _STRUCTURED_PROC before #include'ing.

Nowadays Linux kernels produce multithreaded core dumps with multiple
N_PRSTATUS notes.  That is rather redundant because that structure contains
a bunch of per-process, not per-thread, values.  But it's what Linux does,
and so that format's support gets tested.

That said, using the lwpstatus format may well work just fine after fixing
this one bug, and it is a cleaner format.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]