__libc_fatal public version?
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Wed Dec 31 12:28:59 GMT 2025
On 30/12/25 11:07, Cristian Rodríguez wrote:
> Hi:
>
> Many, many low level software requires exactly what __libc_fatal does,
> a way to fail catastrophically with a message in any context.. (well
> in almost any context as long mmap is able to get some virtual memory)
> All the other ways are not as-safe, applications cannot count on them
> been usable in signal handlers for example
>
> Would it be possible that you will consider either :
>
> - export this to userspace or
> - extend the "error" api, something like error_ss , warn_ss or if all
> that is too much
> - implement the equivalent to the netbsd libc functions snprintf_ss,
> vsnprintf_ss
> and leave the implementation of the rest of the code to applications
> providing an example use im the documentation?
>
> Thanks for reading..
It will depend on the kind of interface we are aiming for. Checking the
snprintf_ss interface, it does not support floating-point formats, positional
arguments, or wide characters (which are usually the features that require
large buffers and/or dynamic memory allocations).
The __libc_fatal does not support any message format, so callers will need
to handle it with different APIs, which might add more complexity and be
error-prone (e.g., buffer management to create the message using printf-like
interfaces).
We already have another interface that the loader uses for different printing
(elf/dl-printf.c), which is also quite limited to what the loader requires
(it supports only a subset of printf formats); so it would make sense to
provide something similar.
There is also the question of whether we want atomicity in the kernel interface,
both in the loader and in __libc_message_impl, by using writev with a static
iov struct. This limits the maximum number of arguments in the format string.
The __libc_fatal also dumps the same error message on a mmap-allocated buffer
to help with core dump analysis.
I am not sure what would make more sense, a print-like extension or a error.h
one.
More information about the Libc-alpha
mailing list