[llvm-dev] lld: sigbus error handling

[Rui Ueyama via llvm-dev]

On Mon, Oct 23, 2017 at 6:48 PM, Brian Cain <brian.cain at gmail.com> wrote:

>
>
> On Mon, Oct 23, 2017 at 8:40 PM, Andrew Kelley via llvm-dev <
> llvm-dev at lists.llvm.org> 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?
>>
>>
>>
> It's hard to imagine a "correct" handling for a bus error.  But reporting
> the error seems like a good idea.  Keeping in mind the fact that there's
> very limited things you can do from a signal handler.  See signal(7) for
> details.
>

Exactly. What I was thinking is to call `write(STDERR_FILENO, "Bus error --
disk full?\n",...)` and then call `_exit` when a SIGBUS is raised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/ed392bd2/attachment.html>