Providing <sgidefs.h> for MIPS?

Providing <sgidefs.h> for MIPS?

[Alexey Neyman]

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.

Re: Providing <sgidefs.h> for MIPS?

[Rich Felker]

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

Re: Providing <sgidefs.h> for MIPS?

[Alexey Neyman]

[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.
>