From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14322 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conditional signal safety? Date: Mon, 1 Jul 2019 10:06:31 -0400 Message-ID: <20190701140631.GP1506@brightrain.aerifal.cx> References: <20190629055405.GA22788@voyager> <87imsmidvs.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17477"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14338-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 16:06:48 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhwxD-0004Rw-Tj for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 16:06:48 +0200 Original-Received: (qmail 9612 invoked by uid 550); 1 Jul 2019 14:06:45 -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 9594 invoked from network); 1 Jul 2019 14:06:44 -0000 Content-Disposition: inline In-Reply-To: <87imsmidvs.fsf@oldenburg2.str.redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14322 Archived-At: On Mon, Jul 01, 2019 at 06:21:11AM +0200, Florian Weimer wrote: > * Markus Wichmann: > > > at work yesterday I had to build an exception handler (a signal handler > > for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really > > convenient to just use dladdr() to find out at least what module and > > function PC and LR were pointing to when the exception happened, so I > > used that function. > > Are these signals generated synchronously, by running code? Then the > rules regarding asynchronous signal safety do not apply. That's a meaningful distinction if they're generated by accesses in the application code. If they're generated by accesses from within standard library functions (e.g. because you passed an invalid pointer or one to memory that was intentionally setup to generate them) to a stdlib function, it's just UB, and if you were going to define it, it'd still be an async signal context just because it's async with respect to the interrupted state of the stdlib function being unspecified/unspecifiable. Rich