[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <668C67FE-E8E9-4A2A-8F7C-7B1FD98C0A76@wardco.com>
Date: Mon, 25 Jan 2016 06:56:26 -0800
From: Ward Willats <musl@...dco.com>
To: musl@...ts.openwall.com
Subject: Re: Bits deduplication: current situation
> On Jan 24, 2016, at 7:59 PM, Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
