This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] mips/o32: fix internal_syscall5/6/7
On Thu, 17 Aug 2017, Adhemerval Zanella wrote:
> If I understood correctly Aurelien's suggestion of returning err in v1
> is not ABI strictly so it will end up calling __libc_do_syscall with a
> non-conformant ABI convention (similar to pipe implementation where requires
> assembly specific implementation for a lot of architectures to get this
> right). Again this is something I would really to avoid.
Using $v1 is fine, in ABI terms it's just a part of a `long long' result,
and you can access it in plain C in the caller (shifting and masking
individual 32-bit halves if necessary). I've done it myself in the past
in some bare-metal library code.
> > If everyone but me thinks there's a clear advantage in using such a
> > handcoded stub though, then as I previously noted please adjust the
> > affected MIPS16 stubs to avoid the extra indirection, i.e. you can call
> > `__libc_do_syscall' directly from MIPS16 code as you'd do from regular
> > MIPS or microMIPS code, as the lone reason for the existence of the MIPS16
> > stubs is the inexistence of a MIPS16 SYSCALL instruction.
>
> Ok, I will try to at least check it on qemu. If you have any points on how
> correctly build a mips16 glibc it could be helpful.
Just pass `-mips16' along with CFLAGS. You may have to make sure your
GCC configuration includes/supports a suitable MIPS16 mulitilib though
(i.e. MIPS16 libgcc.a and CRT files of your chosen endianness; check with
`-print-multi-lib' for entries with `@mips16'), to avoid interlinking
scenarios that may not be supported. I don't remember offhand what the
defaults for the individual GCC configurations are, although I'm fairly
sure at least one of `mips-mti-linux-gnu' and `mips-img-linux-gnu'
configurations does have MIPS16 multilibs. Let me know if you have
troubles with that.
Maciej