From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9190 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Mon, 25 Jan 2016 16:37:15 +0100 Message-ID: <20160125153715.GJ9621@port70.net> References: <20160125035925.GA2288@brightrain.aerifal.cx> <668C67FE-E8E9-4A2A-8F7C-7B1FD98C0A76@wardco.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1453736257 26919 80.91.229.3 (25 Jan 2016 15:37:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 15:37:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9203-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 25 16:37:31 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aNjCs-0003Ze-UP for gllmg-musl@m.gmane.org; Mon, 25 Jan 2016 16:37:31 +0100 Original-Received: (qmail 1621 invoked by uid 550); 25 Jan 2016 15:37:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1599 invoked from network); 25 Jan 2016 15:37:27 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <668C67FE-E8E9-4A2A-8F7C-7B1FD98C0A76@wardco.com> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9190 Archived-At: * Ward Willats [2016-01-25 06:56:26 -0800]: > > On Jan 24, 2016, at 7:59 PM, Rich Felker 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 (I believe from /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.)