Re: [gnu-csky] [PATCH v4 06/13] C-SKY: Linux ABI

[Arnd Bergmann <arnd at arndb dot de>]

On Thu, Sep 13, 2018 at 6:35 PM Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 13 Sep 2018, Joseph Myers wrote:
> > On Thu, 13 Sep 2018, Arnd Bergmann wrote:
> > > From what I can tell, mips64, riscv64, nios2, and microblaze are all wrong, and
> > > the generic default would be wrong as well if picked up by anything else (but
> > > nothing seems to use it).
> >
> > A question for cleaning this up and possibly unifying versions of this
> > header: for multi-ABI architectures, in userspace, what are these
> > structures meant to refer to?  The structures that would be produced by a
> > core dump for the current process, as opposed to those that might be
> > produced by a core dump for another ABI?
>
> Also, I tried writing a test for the glibc testsuite to verify
> compatibility of the layout of these structures in the glibc and Linux
> headers, but found that a simple
>
> #include <linux/elfcore.h>
>
> using the installed uapi headers doesn't compile, because of unknown type
> names size_t, elf_greg_t, elf_gregset_t, elf_fpregset_t, elf_fpxregset_t,
> pid_t.  And indeed, e.g. elf_greg_t is not defined in any of the uapi
> headers, for many architectures.  What are the Linux kernel expectations
> regarding installed uapi headers actually being usable from userspace
> without needing additional type definitions provided by the user?

I think the expectations are generally mismatched with reality for our
headers. It's something that's been bugging me for a while and that
is not trivial to fix. We've had developers in the past that tried to
ensure that each exported uapi header can be included by itself,
but they (I forget who last worked on that) got too frustrated over
time to finish the job.  What you found is clearly a bug on our side
and we should try to fix it.

> If that include worked, and produced the expected layout for the ABI used
> in the current compilation, it would be very helpful for writing such
> tests and ensuring bugs in this area can be found and fixed and avoided in
> future (and more general tests of consistency between glibc and Linux
> headers are probably possible as long as includes of the Linux headers
> from make headers_install do reliably compile without external
> dependencies).

Agreed. I think the main problem is that the kernel still provides certain
types that are also provided by the C library, and other kernel headers
have interdependencies with these.

One example that is particularly nasty are kernel structures that
are defined in terms of 'timeval' and 'timespec'. Those are provided
by either <time.h> or <linux/time.h>, with an inconsistent set of
#ifdef guards between them, and (in the future) incompatible definitions.

Some instances in the kernel need to get changed to a type that
is independent of the libc type (e.g. the elf_prstatus here), while
others need to use the libc type (e.g. ioctl structures with
CLOCK_REALTIME timestamp members), and then need to include
<time.h> in user space.

        Arnd