Re: Bits deduplication: current situation

[Szabolcs Nagy <nsz@port70.net>]

* Ward Willats <musl@wardco.com> [2016-01-25 06:56:26 -0800]:
> > On Jan 24, 2016, at 7:59 PM, Rich Felker <dalias@libc.org> wrote:
> > 
> > signal.h: Arch-specific, and currently omits siginfo_t which is
> > gratuitously different on mips (and thus broken). Moving siginfo_t
> > into it would add A LOT of duplication and maintenance burden unless
> > we have an elaborate bits generation system that can piece these
> > headers together from multiple parts so the siginfo_t part can be
> > shared by all but mips.
> > 
> 
> Just curious. On our OpenWRT-based MIPS platform where our app uses MUSCL, we include <signal.h> (I believe from <somewhere>/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_musl-1.1.11/include/signal.h) and it defines a siginfo_t. But when we use it in a handler to catch faults ( SEGV, ILL, BUS, FPE ), the PC value of the faulting instruction is always non-existent or wrong, as is the errno. The fault subcode is also always zero.
> 
> I always figured this was a result of a bad build or bugs on our side, but reading this makes me wonder if the siginfo_t machinery on our MIPS platform is just not trustworthy in the first place? If so, can it be worked around?
> 

siginfo_t is broken in musl for mips, see this thread:
http://www.openwall.com/lists/musl/2015/12/10/3

si_code and si_errno are swapped in the struct and
some SI_* macros are wrong.

(this happens sometimes in musl because we dont use kernel
headers since they can cause various problems so musl
has to replicate all the kernel uapi quirks.

e.g. bionic uses autogenerated headers to solve this problem
https://android.googlesource.com/platform/bionic/+/master/libc/kernel/README.TXT
but those headers still have lot of issues and the tools
for generating the headers are fairly complex

i think for musl some test tool to compare against linux
uapi would be better than autogen.)