[llvm-dev] lld: sigbus error handling

[Brian Cain via llvm-dev]

On Mon, Oct 23, 2017 at 9:49 PM, Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> ...
>


> It's starting to look to me like that might be necessary to integrate with
> LLD, if I want to handle this SIGBUS error. I'd like to handle out of disk
> space gracefully and not crash.
>
>
It seems to me like command-line-lld should behave this way also.  Though I
can appreciate the convenience and benefits of mmap() over write().  And I
would expect the performance impact of posix_fallocate() could be
significant on some filesystems, as Rui indicates.  It's too bad there's no
interface to put it in the background and find out its progress other than
"gee, what happens if we touch this page?"

Would it make any sense to amortize the expense over multiple
posix_fallocate() calls?  Just posix_fallocate() enough to hit whatever
offset we're using into the mmap plus the size of the write (rounded up to
the next block).  I suppose it's a relatively inexpensive call if we've
already allocated enough space.  If the posix_fallocate() fails we can
gracefully report the disk space exhaustion.


> Here are my concerns:
>
>  * My frontend is cross-platform, so I would also need to figure out how
> this would work on Windows, and eventually on other OSes too. Installation
> of my frontend is simpler if there is not more than 1 executable to
> distribute.
>  * This isn't working right now, but I want the errors of linking to
> provide meaningful error codes and other metadata in a format the frontend
> can associate with  its own state and and handle/render the errors in its
> own way. If this is done via IPC it has to go through a
> serialization/deserialization step.
>  * One of the use cases for my frontend is as a server where it may invoke
> the linker repeatedly. I haven't tested the difference in performance or
> resource usage yet, but it seems to me that LLD as a library / no forking
> would be more efficient.
>  * I would rather compile against LLVM  and clang statically for
> performance and ease of installation (at least on Windows). If LLD is a
> separate binary it would additionally need LLVM/Clang linked in statically,
> and this is a duplicate copy of LLVM/Clang, doubling the size of my
> compiler releases. Further the LLVM initialization code can be shared
> between my frontend and LLD when linked into the same binary.
>
>
>


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/48df3167/attachment.html>