Re: [PATCH] Add SYSCALL_LONG/SYSCALL_ULONG to pass long to syscall [BZ #25810]

["H.J. Lu" <hjl.tools@gmail.com>]

On Sat, Apr 11, 2020 at 8:31 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * H. J. Lu:
>
> > On Sat, Apr 11, 2020 at 8:10 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * H. J. Lu:
> >>
> >> > On Sat, Apr 11, 2020 at 7:45 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> >> >>
> >> >> * H. J. Lu:
> >> >>
> >> >> > On Sat, Apr 11, 2020 at 3:01 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> >> >> >>
> >> >> >> * H. J. Lu via Libc-alpha:
> >> >> >>
> >> >> >> > For inline syscalls, SYSCALL_LONG and SYSCALL_ULONG are introduced as
> >> >> >> > wrappers for long and unsigned long arguments.
> >> >> >>
> >> >> >> Do the arguments have the correct types?  Then I think you can do the
> >> >> >
> >> >> > Yes, they have correct types.  But it is not the problem.  Take this example:
> >> >> >
> >> >> > int munmap(void *addr, size_t length);
> >> >> >
> >> >> > The type of length is unsigned int (size_t) for x32 and is unsigned long
> >> >> > (64bit) in kernel.  We have no way to know the type which kernel expects.
> >> >>
> >> >> Is it possible to extend all 32-bit arguments?  Ot is this incorrect
> >> >> for negative int arguments, which must not have their upper bits set?
> >> >
> >> >       ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp,
> >> >                       int msgflg);
> >> >
> >> >       * If msgtyp is 0, then the first message in the queue is read.
> >> >
> >> >        * If  msgtyp  is greater than 0, then the first message in the queue of
> >> >          type msgtyp is read, unless MSG_EXCEPT was specified  in  msgflg,  in
> >> >          which case the first message in the queue of type not equal to msgtyp
> >> >          will be read.
> >> >
> >> >        * If msgtyp is less than 0, then the first message in  the  queue  with
> >> >          the  lowest  type  less than or equal to the absolute value of msgtyp
> >> >          will be read.
> >> >
> >> > In this syscall, msgtyp should be sign-extended to 64-bit.
> >>
> >> As far as I can tell, this is not a problematic exception.
> >
> > There is no need to extend int nor unsigned int passed to kernel.
> > Only long and unsigned long are the problem.
>
> But is there harm in sign-extending int?
>
> I'm not convinced to annotate INLINE_SYSCALLs in this way just to
> avoid argument extensions for a subset of the x32 system calls.

What x32 needs are

1. Pointer arguments: no cast.
2. 64-bit integer arguments:  no cast.
3. 32-bit integer arguments: extend to 64 bits.

I am having a very hard time to do it  in INLINE_SYSCALLs.   If
SYSCALL_LONG and SYSCALL_ULONG isn't an option, I can
duplicate the whole set of these functions and convert them in
x32 directory.

-- 
H.J.