__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