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. 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/516c1428/attachment.html>
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>
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>
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>