From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9189 Path: news.gmane.org!not-for-mail From: Ward Willats Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Mon, 25 Jan 2016 06:56:26 -0800 Message-ID: <668C67FE-E8E9-4A2A-8F7C-7B1FD98C0A76@wardco.com> References: <20160125035925.GA2288@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3117\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1453733822 17014 80.91.229.3 (25 Jan 2016 14:57:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 14:57:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9202-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 25 15:56:57 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 1aNiZY-0007Ey-Ua for gllmg-musl@m.gmane.org; Mon, 25 Jan 2016 15:56:53 +0100 Original-Received: (qmail 27898 invoked by uid 550); 25 Jan 2016 14:56:50 -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 27863 invoked from network); 25 Jan 2016 14:56:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wardco.com; s=wardco01; h=To:References:Message-Id:Content-Transfer-Encoding:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=FyxXFRTxPfd4Xa6/uEhV3sJgv+FXMI/AF0CSIHkoFOc=; b=YVc1dyzMchZntpI+G4uESYyQu+ GfvEjyXyJOQWUVLBYn1F6AR1OXEZpzzhgpaqvN1/s6btOa2vFnFprLi78w7x9K0y5wxetEB/g0Ghp /0TUfQ167sPprK37FRD4ij97OAAxSF1Rfq5+VjgyxCSpINddbTn9B6vQ/7V84/Ct7yE8=; In-Reply-To: <20160125035925.GA2288@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.3117) X-Spam-Score: -2.9 X-SA-Exim-Connect-IP: 73.71.93.113 X-SA-Exim-Mail-From: musl@wardco.com X-SA-Exim-Scanned: No (on mail.wardco.com); SAEximRunCond expanded to false Xref: news.gmane.org gmane.linux.lib.musl.general:9189 Archived-At: > On Jan 24, 2016, at 7:59 PM, Rich Felker wrote: >=20 > 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. >=20 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? Thanks, -- Ward