This is the mail archive of the libc-alpha@sources.redhat.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: Miscellaneous hppa syscall fixes


On Wed, Jun 06, 2001 at 01:42:57PM +0200, Andreas Jaeger wrote:
> > 	* sysdeps/unix/sysv/linux/hppa/getrlimit.c: remove
> > 	* sysdeps/unix/sysv/linux/hppa/setrlimit.c: remove
> 
> Applied.

Thanks!

> Btw. what about setrlimit64 and getrlimit64?  Are those handled
> correctly?

I believe so.  Here's why:

sysdeps/unix/sysv/linux/hppa/getrlimit64.c:

#include <sysdeps/unix/sysv/linux/i386/getrlimit64.c>

which does:

#define getrlimit64 __new_getrlimit64
#include <sysdeps/generic/getrlimit64.c>
#include <shlib-compat.h>
versioned_symbol (libc, __new_getrlimit64, getrlimit64, GLIBC_2_2);

So it ends up resolving to the right thing.  It would probably be nicer to
simply #include <sysdeps/generic/getrlimit64.c> in .../hppa/getrlimit64.c
but I'm not sure.

> > 	* sysdeps/unix/sysv/linux/hppa/msgctl.c: new file
> > 	* sysdeps/unix/sysv/linux/hppa/semctl.c: new file
> > 	* sysdeps/unix/sysv/linux/hppa/shmctl.c: new file
> 
> Not applied yet.  Please rethink this: The alpha implementation
> handles old and new syscalls, sets __IPC_64 etc - and I do not think
> you want this.  You should at least define __ASSUME_32BITUIDS for
> hppa.

We do define __ASSUME_32BITUIDS; I think we have a bit of a mess here,
let me see if I can untangle it a bit.

 * Very early on, for HPUX compatibility reasons, we defined uid_t and
   gid_t to be 32-bit in the kernel.

 * It seems some header files were not updated at the same time --
   specifically those related to sysv IPC/SHM/etc.

 * there was a desire to retain backwards compatibility with applications
   which had been compiled against those headers.  I suspect that desire
   has now vanished.

 * the 64-bit kernel 32-bit compatibility layer explicitly rejects
   commands which don't have __IPC_64 set.  (There is no pa64 userspace
   yet).

So... we're currently in the situation where glibc always sets the bit
and the kernel always clears the bit.  Not a terribly sensible thing to
be doing.  I suspect the right thing to do is to fix the kernel to ignore
the IPC64 flag and always return the ipc64 struct to userspace on hppa,
then change glibc to not bother setting the flag.

-- 
It's always legal to use Linux (TM) systems
http://www.gnu.org/philosophy/why-free.html


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