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

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 13:44 04.02.00 , Mark Kettenis wrote:
>    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.

Ok, I'll send a new patch then.


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

I assume the ARM people are reading this and will act accordingly :-).


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

OK.


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

gdb-4.18 + Kevin Buettners 4.17 Linux/PPC patch modified by Gary Thomas for 
4.18 + some minor stuff from me. Currently we are eagerly awaiting Kevin 
Buettner to checkin his changes into the gdb repository, that should happen 
"soon" :-).


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

Hmm, I haven't looked at the AltiVec code in the kernel yet, my goal for 
now was just to keep glibc compilabe on current kernels. I'm cc'ing to the 
kernel developers.

Franz.