similar to: [LLVMdev] MemoryBuffer/raw_ostream hybrid for linker?

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. If this were the only problem, I'd suggest just generalizing

For the reasons listed in my 03-May-2012 email, I am proposing a new llvm/Support class for using in writing binary files: /// OutputBuffer - This interface provides simple way to create an in-memory /// buffer which when done will be written to a file. During the lifetime of /// these objects, the content or existence of the specified file is undefined. /// That is, creating an OutputBuffer

On May 8, 2012, at 3:41 PM, Michael Spencer wrote: > On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote: >> For the reasons listed in my 03-May-2012 email, I am proposing a new >> llvm/Support class for using in writing binary files: >> >> /// OutputBuffer - This interface provides simple way to create an in-memory >> /// buffer

On May 8, 2012, at 4:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On May 8, 2012, at 3:41 PM, Michael Spencer wrote: > >> On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote: >>> For the reasons listed in my 03-May-2012 email, I am proposing a new >>> llvm/Support class for using in writing binary files: >>>

On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote: > For the reasons listed in my 03-May-2012 email, I am proposing a new > llvm/Support class for using in writing binary files: > > /// OutputBuffer - This interface provides simple way to create an in-memory > /// buffer which when done will be written to a file. During the lifetime > of >

FWIW, I'd be interested in working on the Windows implementation. I've been knee-deep in *nixes lately and wouldn't mind the refresher. :) Gordon Keiser Software Development Engineer Arxan Technologies w:+1.765.889.4756 gkeiser at arxan.com www.arxan.com<http://www.arxan.com/> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nick

On May 8, 2012, at 3:52 AM, Gordon Keiser wrote: > FWIW, I'd be interested in working on the Windows implementation. I've been knee-deep in *nixes lately and wouldn't mind the refresher. J Cool! Does my proposed interface make sense to implement on top of Windows APIs? -Nick > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";

On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Dear all, > > Consider there is a program that writes to stdout using two different > raw_fd_ostream-s: raw_fd_ostream does buffered I/O, so it's not really meant to be used like this. > #include "llvm/LLVMContext.h" > #include "llvm/Module.h" > #include

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:

> On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <viacheslav.nikolaev at gmail.com> wrote: > > > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write(). > > Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted? > I cannot see if that is so. And I really saw it didn't

On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path,

Hi, When I run the below example, it results in :- hello world LLVM ERROR: IO failure on output stream. Testcase :- #include <llvm/Support/raw_ostream.h> int fn() { std::string errorInfo; llvm::raw_fd_ostream out("-", errorInfo); out << "world\n"; return 0; } int main(int argc, char **argv) { llvm::outs() << "hello\n"; fn();

Hi Dan, lld takes a -emit-yaml option, which emits the intermediate representation(atoms) in YAML form. By default output goes to stdout, the user can control it by using the -o option too. The way its handled is, similiar to this piece of pseudo-code if (dash_o_option) outputFile = dash_o_option->value() else outputFile = "-" When lld tries to mix things that go to

Would it be appropriate for lld's other output to go to standard error instead of standard output, since standard output may be used for YAML output? Dan On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default

The high-level answer is that library code shouldn't hardcode output paths, including "-" and including using llvm::outs(). Library code should (in general) instead accept an ostream in its API and write to wherever it is being asked to write. If this is followed, the only place in any program using llvm::outs() is code which is not part of a "library" -- i.e. it is the

Hi Dan, The other messages, need to go to stdout as well. Using stderr to output for a switch like --verbose is wrong in my opinion. On 8/14/2013 4:44 PM, Dan Gohman wrote: > Would it be appropriate for lld's other output to go to standard error > instead of standard output, since standard output may be used for YAML > output? > > Dan > > On Wed, Aug 14, 2013 at 12:53

Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Dan On Wed, Aug 14, 2013 at 2:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > The other messages, need to go to

Hi, All I m not sure if this question has been asked or not. I'd like cache the MCJIT compiled object into memory buffer so it can be reused later. I followed the Andy Kaylor's example wrote an inherited class from ObjectCache and use raw_fd_ostream to save the cache and load the cache from a file. I checked raw_ostream and its subclass, maybe I am wrong but I don't see one is fit to

This code from raw_ostream.h is really racy: raw_ostream &operator<<(StringRef Str) { // Inline fast path, particularly for strings with a known length. size_t Size = Str.size(); // Make sure we can use the fast path. if (Size > (size_t)(OutBufEnd - OutBufCur)) return write(Str.data(), Size); if (Size) { memcpy(OutBufCur, Str.data(), Size);