[llvm-dev] lld: sigbus error handling
Brian Cain via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 23 18:48:59 PDT 2017
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.
ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/31d1c50d/attachment.html>
More information about the llvm-dev
mailing list