Re: Bits deduplication: current situation

[Ward Willats <musl@wardco.com>]

> 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?

Thanks,

-- Ward