[llvm-dev] lld: sigbus error handling

[Andrew Kelley via llvm-dev]

On Mon, Oct 23, 2017 at 9:30 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Mon, Oct 23, 2017 at 5:28 PM, Andrew Kelley <superjoe30 at gmail.com>
> wrote:
>
>> For Zig we use LLD as a library. So for us it would be better to avoid
>> global state such as SIGBUS (or any other signal handlers), instead
>> returning an error from the link function when linking fails. If lld can
>> encapsulate this signal handling and prevent the application using lld from
>> getting the signal directly, instead carefully handling the signal in LLD
>> itself and translating it into a proper error code or message, this would
>> be reasonable.
>>
>
> Signal handlers and signal masks are inherently process-wide, so there's
> no way to encapsulate them to lld functions. So my plan is to change the
> name of lld::{coff,elf}::link's `ExitEarly` parameter to `IsStandalone`,
> and we (not only call exit(2) but also) set a signal handler only when the
> argument is true. Since library users pass false to the parameter, it
> shouldn't change the behavior of lld for the library use case.
>

This sounds good to me.

And then if an application wants to handle the SIGBUS correctly, it would
have to register this signal handler to report the error?


>
> On Mon, Oct 23, 2017 at 6:21 PM, Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> If your system does not support fallocate(2), we use ftruncate(2) to
>>> create an output file. fallocate(2) succeeds even if your disk have less
>>> space than the requested size, because it creates a sparse file. If you
>>> mmap such sparse file, you'll receive a SIGBUS when the disk actually
>>> becomes full.
>>>
>>> So, lld can die suddenly with SIGBUS when your disk becomes full, and
>>> currently we are not doing anything about it. It's sometimes hard to notice
>>> that that was caused by the lack of disk space.
>>>
>>> I wonder if we should print out a hint (e.g. "Bus error -- disk full?")
>>> when we receive a SIGBUS. Any opinions?
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/5a68f3ff/attachment.html>