[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 01 Jul 2019 17:55:07 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Conditional signal safety?
* 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
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.
