[llvm-dev] lld: sigbus error handling

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 23 18:48:10 PDT 2017


On Mon, Oct 23, 2017 at 6:40 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:

>
>
> 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?
>

I could export a function that sets a signal handler as part of the library
interface, but I'm reluctant to do that because you can do the same thing
in a few lines of C code.

Can I ask you a question? I wonder if there's a reason to not call fork
before calling lld's main function.


>
>>
>> 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/3330c1e0/attachment.html>


More information about the llvm-dev mailing list