similar to: [LLVMdev] Should file opening error during raw_fd_stream::raw_fd_stream exit instead of passing the error up to the caller?

Since FreeBSD is an ELF target, this should work fine. I've also tested that this works in 32-bit by building gdb and llvm in 32-bit mode and testing this stuff while running on a 64-bit OS. I would try setting a breakpoint in gdb on 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being called, and that getELFWriterInfo returns something. If that function actually

On 06/21/2010 11:14, Reid Kleckner wrote: > Yes, I have some version of 7.1 installed on my workstation and it works for me. I repeted what you did step by step and it still doesn't work for me, see log below. Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter. Yuri $ lli

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this should work fine. I've also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called,

I was just fixing a bug that was caused by `stdout` being closed before the runtime has done `fflush(stdout)` [or however this is implemented in the runtime]. The cause of this seems to be that `outs()` returns a static object created from `raw_fd_stream(STDOUT_FILENO, true)` - the `true` being the `shouldClose` parameter. Surely LLVM is not supposed to close `stdout` as part of its operations?

On 22 November 2010 20:52, Jason Kim <jasonwkim at google.com> wrote: > So far, for X86 identical ELF relocation flags show up in > > include/llvm/Support/ELF.h and > lib/Target/X86/X86ELFWriterInfo.h > > Not to mention, there are two different files named ELF.h I would say that ELF.h should be the canonical one. > ./lib/CodeGen/ELF.h > ./include/llvm/Support/ELF.h

On 06/19/2010 14:03, Yuri wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that functions occupy in memory > while they run in JIT. File format generated is like this: > ... > 0x5000000 0x5001000 function_name_is_here > ... > > This feature is useful for external tools like valgrind and >

the reason I built llvm with vc is that I am familiar with vc. At first i also thing that build llvm with MingW will solve this problem. but after I read the source code void JITDebugRegisterer::RegisterFunction(const Function *F, DebugInfo &I) { // TODO: Support non-ELF platforms. if (!TM.getELFWriterInfo()) return; ...... } I thing MinGW is helpless with debug jit on win.

We've had this argument before. IMO LLVM should not be in the business of closing stdout, and no code in lib/ should print to stdout because users may expect output there (-o -). On Fri, Jan 23, 2015 at 10:20 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jan-23, at 09:52, mats petersson <mats at planetcatfish.com> wrote: > > > >

Oh, well... as usually the answer appears to be pretty obvious. 99% of the time is spent inside the plain write. -print-after-all prints into llvm::errs(), which is an *unbuffered* raw_fd_stream. And -git-commit-after-all opens a *buffered* raw_fd_stream. As soon as I hacked -print-after-all to use a buffered stream to stderr performance went up to the normal expected values: ] time bin/opt

On 06/23/2010 23:44, Chris Lattner wrote: > This doesn't seem specific to the JIT. Can you add this to the normal code generator, and have the JIT leverage off that? Here are some minor comments, but the bigger issue of how this integrates seems important. > Why this isn't specific to JIT? It outputs memory addresses of functions while they are run in JIT. Can code be run

Hello, Just an update on that. I am personally using -git-commit-after-all *as-is* extremely frequently (combined with "git filter-branch" and "opt -S -instnamer" it is extremely useful). I unfortunately won't have time to write a better implementation of that, and I agree "git fast-import" seems the way to go. If anybody is motivated enough to do so, feel free.

On Jun 22, 2010, at 4:18 PM, Yuri wrote: > On 06/19/2010 14:03, Yuri wrote: >> This new option (--jit-emit-debug-function-range) will allow to output >> function information for memory ranges that functions occupy in memory >> while they run in JIT. File format generated is like this: >> ... >> 0x5000000 0x5001000 function_name_is_here >> ... >>

On Jun 24, 2010, at 12:02 AM, Yuri wrote: > On 06/23/2010 23:44, Chris Lattner wrote: >> This doesn't seem specific to the JIT. Can you add this to the normal code generator, and have the JIT leverage off that? Here are some minor comments, but the bigger issue of how this integrates seems important. >> > > Why this isn't specific to JIT? It outputs memory

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!";

So far, for X86 identical ELF relocation flags show up in include/llvm/Support/ELF.h and lib/Target/X86/X86ELFWriterInfo.h Not to mention, there are two different files named ELF.h ./lib/CodeGen/ELF.h ./include/llvm/Support/ELF.h I'd think the latter should be renamed MCELFSupport.h Thanks! -jason

Hi all, In a pass I’m using raw_fd_ostream to write a string to a file. Does raw_fd_ostream guarantee the write is atomic when I do parallel compilation (currently I’m using -j8)? I have some errs() to print information for debugging purposes and I saw that the printed information gets messed up sometime. If I’m writing a string with the format of “A:B:C”, is it possible that I got “A1:B2:C1” and

Hello, The following describes an API change on trunk. The change is not in the 2.6 branch. The raw_fd_ostream class now defaults to overwriting its output file, and the F_Force flag which was introduced only recently is gone. There's a new F_Excl flag to support users wanting the behavior of returning an error if the file exists, though no one actually appears to want this.

Note that raw_fd_ostream is not seekable, and hence will not be suitable as addPassesToEmitFile output stream. 2016-02-22 18:27 GMT+02:00 Rafael Espíndola <llvm-dev at lists.llvm.org>: > On 22 February 2016 at 11:16, Frank Winter <fwinter at jlab.org> wrote: > > TargetMachine::CGFT_AssemblyFile is exactly what I am trying to write > out. > > I see. > > For

On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: > . For many applications > other than LLVM itself, the basic LLVM <=2.5 interface which just > overwrites existing files is all that's ever needed. On LLVM trunk, raw_fd_ostream is now back to overwriting files by default, as it is the unanimous preference among in-tree users (and out-of-tree users that I'm aware of). Dan

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