This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: A PPC patch for glibc 2.1
- To: hjl@lucon.org
- Subject: Re: A PPC patch for glibc 2.1
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Thu, 3 Dec 1998 21:27:53 +1100
- CC: howarth@bromo.med.uc.edu, libc-hacker@cygnus.com
- References: <m0zlSBw-000393C@ocean.lucon.org>
> From: hjl@lucon.org (H.J. Lu)
> Date: Wed, 2 Dec 1998 22:24:44 -0800 (PST)
> Cc: libc-hacker@cygnus.com (GNU C Library)
>
> Hi,
>
> This patch is needed by my upcoming gdb 4.17.0.6.
What's wrong with the existing files? The following works fine for
me in 2.0.104:
[geoffk@geoffk geoffk]$ cat > x.c
#include <sys/types.h>
#include <sys/user.h>
#include <sys/procfs.h>
[geoffk@geoffk geoffk]$ gcc x.c -c
[geoffk@geoffk geoffk]$
Your sys/procfs.h seems to be nearly identical to the existing one, it
just uses the sys/ header files not the asm/ ones. If this is how
it's supposed to work, it would be better to change the generic
version. Your sys/user.h seems to be effectively identical to the
existing one.
> --- /dev/null Tue May 5 13:32:27 1998
> +++ sysdeps/unix/sysv/linux/powerpc/sys/elf.h Wed Dec 2 21:34:45 1998
> +#define ELF_EXEC_PAGESIZE 4096
Shouldn't this be 64k? Or is it supposed to vary with CPU type?
> +/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
> + use of this is to invoke "./ld.so someprog" to test out a new version of
> + the loader. We need to make sure that it is out of the way of the program
> + that it will "exec", and that there is sufficient room for the brk. */
> +
> +#define ELF_ET_DYN_BASE (0x08000000)
This varies by kernel version. You must test it at runtime if you
need it. On my machine it is 0x2aaab000. On some previous linux-ppc
versions it was 0x30000000. It may change again. Really, ld.so
should relocate itself if it detects a conflict.
Perhaps it would be better if you only defined the things you really
needed. But I can't see anything at all in this file that you should
need! They are all either stored in the core file, or don't seem to
be particularly relevant to a debugger. What have I missed?
--
Geoffrey Keating <geoffk@ozemail.com.au>