* Re: Providing <sgidefs.h> for MIPS?
2017-01-26 7:31 Providing <sgidefs.h> for MIPS? Alexey Neyman
@ 2017-01-26 14:53 ` Rich Felker
2017-02-04 20:49 ` Alexey Neyman
1 sibling, 0 replies; 3+ messages in thread
From: Rich Felker @ 2017-01-26 14:53 UTC (permalink / raw)
To: musl
On Wed, Jan 25, 2017 at 11:31:27PM -0800, Alexey Neyman wrote:
> Hi,
>
> In crosstool-ng, a failure to build native GDB for mips-*-mips has
> been reported: https://github.com/crosstool-ng/crosstool-ng/pull/517
>
> The reason is a missing <sgidefs.h> header (which is provided by
> glibc/uClibc, but not by musl). The reporter suggested to use
> <asm/sgidefs.h> from the Linux kernel instead. However, GDB
> developers seem to disagree:
> https://sourceware.org/ml/gdb-patches/2017-01/msg00446.html; their
> view is that the <sgidefs.h> header is to be provided as a part of
> the user-space headers.
>
> Should musl provide one?
I don't think so. This is a legacy OS-vendor-specific header that
should not be provided or used at all, much less in musl. An easy way
for distros to make gdb happy would be just to ship an sgidefs.h, but
really gdb should be using the compiler-predefined macros (e.g.
_MIPS_SIM, _ABI64, etc. like musl's configure script does) rather than
a silly SGI header that just provides the same things by different
names, unless the OS part of the tuple is irix.
Rich
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Providing <sgidefs.h> for MIPS?
2017-01-26 7:31 Providing <sgidefs.h> for MIPS? Alexey Neyman
2017-01-26 14:53 ` Rich Felker
@ 2017-02-04 20:49 ` Alexey Neyman
1 sibling, 0 replies; 3+ messages in thread
From: Alexey Neyman @ 2017-02-04 20:49 UTC (permalink / raw)
To: musl
[Sorry for not CC'ing, Richard Felker - I am not subscribed to this
list, so I only saw your response on the website as you only replied to
the list]
Relaying one more response from GDB maintainers:
[[[[
NB the published API set out by SGI is actually <sys/asm.h> [1][2][3]
rather than <sgidefs.h>, so if musl does the right thing via the former
header then I'll be happy to accept a patch to switch. Otherwise I'll be
closing the bug as invalid.
References:
[1] "MIPSpro Compiling and Performance Tuning Guide", Silicon Graphics,
Inc., Document Number 007-2360-008, Section 6.3.2 "Using Predefined
Types", p. 135
<http://techpubs.sgi.com/library/manuals/2000/007-2360-008/pdf/007-2360-008.pdf>
[2] "MIPSpro 64-Bit Porting and Transition Guide", Silicon Graphics, Inc.,
Document Number 007-2391-006, Section "Using a Different Subrouting
Linkage", p. 45
<http://techpubs.sgi.com/library/manuals/2000/007-2391-006/pdf/007-2391-006.pdf>
[3] "MIPSpro N32 ABI Handbook", Silicon Graphics, Inc., Document Number
007-2816-004, Section "Using a Different Subroutine Linkage", p. 22
<http://techpubs.sgi.com/library/manuals/2000/007-2816-004/pdf/007-2816-004.pdf>
]]]]
I don't have a particular stake in this game, but if it is a de-facto
standard for MIPS, musl might want to adhere to it.
Regards,
Alexey.
On 01/25/2017 11:31 PM, Alexey Neyman wrote:
> Hi,
>
> In crosstool-ng, a failure to build native GDB for mips-*-mips has
> been reported: https://github.com/crosstool-ng/crosstool-ng/pull/517
>
> The reason is a missing <sgidefs.h> header (which is provided by
> glibc/uClibc, but not by musl). The reporter suggested to use
> <asm/sgidefs.h> from the Linux kernel instead. However, GDB developers
> seem to disagree:
> https://sourceware.org/ml/gdb-patches/2017-01/msg00446.html; their
> view is that the <sgidefs.h> header is to be provided as a part of the
> user-space headers.
>
> Should musl provide one?
>
> Regards,
> Alexey.
>
^ permalink raw reply [flat|nested] 3+ messages in thread