From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14329 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conditional signal safety? Date: Mon, 01 Jul 2019 17:55:07 +0200 Message-ID: <87h885bvhg.fsf@oldenburg2.str.redhat.com> References: <20190629055405.GA22788@voyager> <87imsmidvs.fsf@oldenburg2.str.redhat.com> <20190701140631.GP1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="223442"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14345-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 17:55:37 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 1hhyeW-000w2E-UM for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 17:55:36 +0200 Original-Received: (qmail 9962 invoked by uid 550); 1 Jul 2019 15:55:35 -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 9938 invoked from network); 1 Jul 2019 15:55:34 -0000 In-Reply-To: <20190701140631.GP1506@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 1 Jul 2019 10:06:31 -0400") X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 01 Jul 2019 15:55:15 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14329 Archived-At: * Rich Felker: > 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. Right, but if libc code traps without violating preconditions, that's generally a bug. And if you violate preconditions, than *that* already triggers undefined behavior, and not the trap later on. (For example, the compiler uses the knowledge of well-known functions and optimizes accordingly.) Thanks, Florian