Date: Mon, 17 Sep 2018 09:24:28 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Replacing a_crash() ? On Mon, Sep 17, 2018 at 01:13:50PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [2018-09-16 23:23:17 -0400]: > > Now that we have an abort() that reliably terminates with uncatchable > > SIGABRT, I've been thinking about replacing the a_crash() calls in > > musl (which are usually an instruction generating SIGILL or SIGSEGV) > > with calls to the uncatchable tail of abort(), which I would factor > > off as a __forced_abort() function. > > > > In case it's not clear, the reason for not just calling abort() is > > that too many programs catch it, and catching it is even encouraged. > > Catchability is a problem with the current approach too, since > > a_crash() is used in places where process state is known to be > > dangerously corrupt and likely under attacker control; eliminating it > > is one of the potential goals of switching to __forced_abort(). > > i wonder if it can be made debugging friendly in some way, > e.g. with multiple failure paths merged into a single > __forced_abort call or when it's tail called, it may > not be clear from a core dump why the abort happened. > > if __forced_abort(const char *reason) stored its argument > somewhere that is not clobbered then it may be easier to > figure out what went wrong. (you would still need some > debug skills to look at the reason though..) I think gcc already does something to make _Noreturn functions easier to debug like this, doesn't it? There's really not much advantage to a tail call when the function won't return. Rich
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.