[PATCH v8 6/6] elf: Raise SIGABRT for assert within ld.so

[Florian Weimer]

* Florian Weimer:

> * Adhemerval Zanella:
>
>> The assert static path already properly raises SIGABRT for assert during
>> process startup, while ld.so only prints the error message and issues
>> _exit.  This prevents a coredump from being created if the environment
>> is configured to do so.
>>
>> Similar to rtld malloc hooks, the assert symbol __assert_fail and
>> assert_perror_fail need to be relocated to the libc symbol after the
>> final relocation (so dlfcn.h functions call libc __assert_fail instead
>> of dl-minimal.c one). The hook framework is renamed to be more generic,
>> instead of tying to rtld malloc.
>>
>> The Hurd requires a proper __raise_direct implementation, issuing raise
>> or kill pull a lot of symbols that prevents ld.so building.
>>
>> Checked on x86_64-linux-gnu and i686-linux-gnu.
>
> Is it really necessary to provide an interceptable assert for ld.so
> assertion failures?  We could reset the handler unconditionally and then
> send SIGABRT (in a loop, due to race conditions).
>
> With this approach, we wouldn't need stubs that get later replaced with
> the libc implementation.
>
> I don't think providing SIGABRT interception capabilities is woth the
> complexity.

I've since received the opposite feedback from an ISV: they absolutely
want their in-process crash handler to run when glibc aborts in ld.so
due to an assertion failure (or just OOM in the current TLS
implementation).  I dislike in-process crash handlers, but it seems this
is still a valid request.  So I'm withdrawing my suggestion.

Thanks,
Florian