![]() |
|
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.