[klibc] Last call for klibc 2.0...

H. Peter Anvin hpa at zytor.com
Mon May 21 10:20:55 PDT 2012

On 05/21/2012 02:31 AM, maximilian attems wrote:
> On Thu, 17 May 2012, H. Peter Anvin wrote:
>> I think it's time to issue an official call for anything missing in
>> klibc 2.0... testing would also be appreciated.
> llseek seems missing in SYSCALLS.def for 64 bit.

Correct, llseek doesn't exist for 64 bits (lseek is 64 bits wide, so no
need for a special hack.  On 32 bits, lseek() is a wrapper around
llseek(), see the misnamed llseek.c (I think I should fix that one.)

> but currently I'm confused why belows is needed to have openat compiled on
> x86_64:
> diff --git a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def
> index 70838b8..73253c3 100644
> --- a/usr/klibc/SYSCALLS.def
> +++ b/usr/klibc/SYSCALLS.def
> @@ -157,6 +157,7 @@ int getcwd::__getcwd(char *, size_t);
>  <!i386,m68k,64> int open::__open(const char *, int, mode_t);
>  <?!i386,m68k,64> int openat::__openat(int, const char *, int, mode_t);
>  <64> int open(const char *, int, mode_t);
> +<64> int openat::__openat(int, const char *, int, mode_t);
>  ssize_t read(int, void *, size_t);
>  ssize_t write(int, const void *, size_t);
>  int close(int);

Good spotting, but wrong fix.  Just like open(), there is no need to
wrapper openat() on 64 bits, so we can just use the system call directly.

The reason we need a wrapper for open() and openat() on 32 bits is so we
can set the O_LARGEFILE flag (klibc *only* supports the
_FILE_OFFSET_BITS=64 programming model, with 64-bit off_t.)


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

More information about the klibc mailing list