This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


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

Re: glibc-2.1.3, asm/elf.h and PPC kernels with AltiVec support


   Date: Fri, 04 Feb 2000 11:46:14 +0100
   From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>

   Well, including them in sys/procfs.h is fine for me, if that's the
   way to go. Probably the ARM people should revert their recently
   introduced sys/elf.h as well? At least that's what I used as a
   template :-) (I only look at x86 stuff as a last resort, other
   platforms are usually much cleaner).

Well, it's just that I've been hacking on GDB (on Linux/i386) and
noticed the almost complete sense of logic in the distribution of
symbols over the specific header files.  My current view is that GDB
only needs <sys/user.h> (for `struct user' that is used to get debugging
information on the process via `ptrace' and for a.out core-dumps)
which pretty much every tradition UNIX system has, and <sys/procfs.h>
(for various structures that are used in ELF core-dumps) that is
inspired on SVR4.  Since there doesn't seem to be the need for a
seperate <sys/elf.h>, I don't think it should be added.

And yes I think that ARM should get rid of <sys/elf.h> too.

   >    > >If there are no objections, I'll put together such a file and post 
   > it later
   >    > >today with the corresponding changes to other files.
   >
   >    This seems to be missing a lot of stuff.  In particular, the
   >    ELF_EXEC_PAGESIZE and ELF_CORE_COPY_REGS macros.
   >
   >Are these really meant to be used in userspace?  GDB doens't use
   >them.  I doubt that they're really needed.

   gdb builds fine for me, so it seems they are really not used. I couldn't 
   find a single reference to these macros in the gdb sources too.

I guess you can get the page size used in core dumps (if you care)
from the ELF headers and that ELF_CORE_COPY_REGS is used internally by
the Linux kernel to copy between the internal representation of the
registers and the representation used in the core dump itself.

Just out of interest, what version of GDB are you using?

And another thing, how is this "AltiVec" support implemented in the
Linux kernel?  I assume they're analogous to the extra registers that
modern Intel & AMD processors have (3DNow), and that they're written
to another special section in a core dump.  If that's the case it
might be worth looking at how GDB (or libbfd) handles core-dumps, and
see if it would be possible to have them dumped in a format that is
easily extendable since without doubt there will be powerpc processors
with even more of those special registers.

Mark

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