LFS meets PowerPC - score 0,1

[Daniel Jacobowitz <drow@false.org>]

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      |
\--------------------------------/  \--------------------------------/