Re: [musl] riscv32 v2

[Arnd Bergmann <arnd@arndb.de>]

On Tue, Sep 8, 2020 at 3:03 AM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Sep 08, 2020 at 12:30:27AM +0200, Arnd Bergmann wrote:
> > On Tue, Sep 8, 2020 at 12:12 AM Rich Felker <dalias@libc.org> wrote:
> > > As an aside, I should probably cleanup the current definition
> > > framework where IPC_64==0x100 is the default and archs that want 0
> > > have to define it explicitly. It looks like, for the most part, IPC_64
> > > is needed iff SYS_ipc is defined.
> >
> > Right, there are no architectures that provide sys_ipc and want the
> > flag to be zero.
> >
> > > Of the archs we support, arm
> > > (32-bit) and mips{n32,64} seem to be the only ones that lack SYS_ipc
> > > but need the IPC_64 bit set. Does this agree with your assessment?
> >
> > I think microblaze is in the same group. Note that for odd reasons it
> > has always defined the __NR_ipc macro to 117 but hooked it up
> > to -ENOSYS instead of sys_ipc in the kernel. I'm never quite sure
> > whether we should treat that as a bug in the header file that we want
> > to fix, or whether we should keep such constants around in new
> > headers that were present in older ones.
>
> Oh, really? In that case musl's almost surely broken on microblaze,
> and yes it would be another exception.

There was (very briefly) a sys_ipc implementation on microblaze
in 2009 as the architecture got merged, but this was never part of
a released kernel as far as I can tell.

I'm not surprised that this was never caught though, as sysvipc
is not that common on the super-small softcore implementations
that microblaze tends to be used for.

On sparc32, sysvipc had been broken in a slightly different way
in the kernel for over 11 years without anyone complaining (it
was working in compat mode on 64-bit kernels though).

For future 64-bit microblaze, we will have to decide which ABI
to use, I'd probably go with the new variant (only split calls,
no IPC_64 flag).

        Arnd