This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5 09/11] nds32: Add ABI list
On Mon, Jun 24, 2019 at 9:54 AM Vincent Chen <vincentc@andestech.com> wrote:
>
> On Fri, Jun 21, 2019 at 09:12:05PM +0800, Arnd Bergmann wrote:
> > On Thu, Jun 20, 2019 at 8:43 AM Vincent Chen <vincentc@andestech.com> wrote:
> >
> > > +++ b/sysdeps/unix/sysv/linux/nds32/c++-types.data
> > > @@ -0,0 +1,67 @@
> > > +blkcnt64_t:x
> > > +blkcnt_t:l
> >
> > Is there a requirement for defaulting to 32-bit blkcnt_t in glibc?
> > The kernel for nds32 has only ever supported 64-bit here, so it
> > seems a bit pointless to use a smaller range in user space.
> >
> > > +fsblkcnt64_t:y
> > > +fsblkcnt_t:m
> > > +fsfilcnt64_t:y
> > > +fsfilcnt_t:m
> >
> > Same for these
> >
> > > +loff_t:x
> > > +off64_t:x
> > > +off_t:l
> >
> > and these
> >
> > > +rlim64_t:y
> > > +rlim_t:m
> >
> > and these
> >
> For nds32, I think your suggestions are reasonable but I have a question about
> rlim_t. The 2nd argument of function sys_getrlimit and sys_setrlimit is struct
> rlimit which consists of 2 __kernel_ulong_t data, rlim_cur and rlim_max, in
> the kernel. If I change the type of rlim_t to unsigned long long, the data type
> of these two parameters does not match between kernel and linux. I know that
> if the macro __RLIM_T_MATCHES_RLIM64_T is defined as 1, glibc will replace the
> system calls getrlimit and setrlimit with prlimit64, and this problem does not
> exist. However, user still can use indirect system call, syscall, to issue
> getrlimit and setrlimit. So, does the data type of rlim_t still keep as
> unsigned long in glibc? or I need to send a patch to kernel to undefine the
> __ARCH_WANT_SET_GET_RLIMIT for nds32.
I think the behavior you need is to set __RLIM_T_MATCHES_RLIM64_T
and define struct rlimit and rlim_t as 64 bit types.
Using syscall() directly from user space has lots of other problems when
the kernel data types and the user space types don't match, e.g. calling
clock_gettime() won't work when you have a 64-bit time_t, that needs to
be clock_gettime64().
Removing __ARCH_WANT_SET_GET_RLIMIT, __ARCH_WANT_STAT64,
and __ARCH_WANT_TIME32_SYSCALLS would be nice in theory to keep
the ABI clean and the kernel small, but we can't do that if anyone is
still using binaries that call these. Whether those exist is probably out
of your control, so the saver option is to keep them around forever.
Arnd