[LLVMdev] [RFC] llvm/include/Support/FileOutputBuffer.h

[Nick Kledzik]

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken).  The patch supports the functionality listed below and I've tested that it works for lld.  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileOutputBuffer.patch
Type: application/octet-stream
Size: 25308 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120517/9ab7084f/attachment.obj>
-------------- next part --------------



To implement the FileOutputBuffer, I needed to add some more functions to llvm/Support/FileSystem.h, including:
   is_writable_file()
   is_executable_file()
   set_file_executable()
   unique_file_sized()
   map_file_pages()
   unmap_file_pages()
I've implemented the unix side for all these, but have the windows side just stubbed out.

I've also added a test case (unittests/Support/FileOutputBufferTest.cpp) which exercises FileOutputBuffer.

-Nick


>>>> 
>>>> On May 3, 2012, at 6:10 PM, Nick Kledzik wrote:
>>>> 
>>>> Existing llvm code tends to use raw_ostream for writing files.  But
>>>> raw_ostream is not a good match for a linker for a couple of reasons:
>>>> 
>>>> 1) When the linker creates an executable, the file needs the 'x' bit set.
>>>> Currently raw_fd_ostream has no way to set that.
>>>> 
>>>> 2) The Unix conformance suite actually has some test cases where the linker
>>>> is run and the output file does exists but is not writable, or is not
>>>> writable but is in a writable directory, or with funky umask values.
>>>> raw_fd_ostream interface has no way to match those semantics.
>>>> 
>>>> 3) On darwin we have found the linker performs better if it opens the output
>>>> file, truncates it to the output size, then mmaps in the file, then writes
>>>> directly into that memory buffer.  This avoids the memory copy from the
>>>> private buffer to the OS file system buffer in the write() syscall.
>>>> 
>>>> 4) In the model we are using for lld, a streaming output interface is not
>>>> optimal.   Currently, lld copies chunks of code from the (read-only) input
>>>> files, to a temporary buffer, then applies any fixups (relocations), then
>>>> streams out that temporary buffer.  If instead we had a big output buffer,
>>>> the linker could copy the code chunks directly to the output buffer and
>>>> apply the fixups there, avoiding an extra copy.
>>>>