Re: Providing <sgidefs.h> for MIPS?

[Alexey Neyman <stilor@att.net>]

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