This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
LFS meets PowerPC - score 0,1
- To: libc-alpha@sourceware.cygnus.com
- Subject: LFS meets PowerPC - score 0,1
- From: Daniel Jacobowitz <drow@false.org>
- Date: Thu, 17 Jun 1999 00:43:14 -0400
I spent today merrily chasing down some of the problems with LFS
support on powerpc-linux; it tends to break everything, totally. I've
found at least one of them.
mmap64 is simply defined as an alias to mmap, for all linux platforms -
specifically defined so for the 64bit arches, as makes sense, and
temporarily defined so for the others. There's one big problem with
the way it's done, though. It is simply a syscall alias, so there are
now two ways to make the mmap syscall - one has a prototype with a
32bit off_t, and the other has a prototype with a 64bit off64_t. In
all honesty, I can't believe this ever worked at all. Perhaps a
wierd combination of endiannesses and calling conventions enabled it to
work on some other architectures, but on ppc we see this:
Assembly for a call to mmap():
li 3,1
li 4,2
li 5,3
li 6,4
li 7,5
li 8,6
bl mmap
And mmap64():
li 3,7
li 4,8
li 5,9
li 6,10
li 7,11
li 9,0
li 10,12
bl mmap64
This would be fine if mmap64 was a wrapper to call mmap(), and perhaps
error out on >32 bit offsets. But mmap64 is an alias of mmap, and thus
goes blithely out into the syscall, without ever having put a value in
r8 as expected.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/