search for: memorybuffers

Recently I started getting these warnings - thousands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning

Hi all, I'm implementing interleaved source in assembly output. Early reviews raised the concern that the current implementation will be opening files (using a llvm::MemoryBuffer) that are likely to be in the memory of the front end (commonly clang but I think we want this to be front end agnostic). I'm now exploring ideas to avoid reopening files and let LLVM reuse the files the FE had

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016763.html On 2008-09-05, at 22:46, Talin wrote: > Recently I started getting these warnings - thousands of them - and > I'm > not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in

all of: ---- // cout << "lsr: " << lsr << "\n"; llvm::MemoryBuffer* mbjit = llvm::MemoryBuffer::getMemBufferCopy (sr); ------ string lsr = sr.str(); // cout << "lsr: " << lsr << "\n";

This segfault occuring only under valgrind, in shell way, and in gdb way i have Invalid bitcode signature simple_scev_dynamic_array: /home/willy/apollo/llvm/include/llvm/Support/ErrorOr.h:258: storage_type *llvm::ErrorOr<llvm::Module *>::getStorage() [T = llvm::Module *]: Assertion `!HasError && "Cannot get value when an error exists!"' failed. Command terminated by

I was writing something using MemoryBuffer, and while looking through its code I came across line 59: assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); I am curious if the MemoryBuffer only supports non-binary, non-null embedded files, or if it supports binary as well. I do not see anything inherently not expecting binary files except for that one line, so I am

Hello Willy, Here is the dump from one of my bitcode files: 0000000 42 43 c0 de 21 0c 00 00 25 05 00 00 0b 82 20 00 As expected, 0x42 (= B), 0x43 (= C), xc0 and 0xde are in correct order. In your case, the first byte is read as 37 (= 0x25). I wonder why? When you check the bytes yourself, you get expected results. When the same bytes are read from Stream object, you get a different result (maybe

Hello list, I learned that under LLVM, #including of <iostream> is forbidden. Instead LLVM provides llvm::raw_ostream(for std::cout, std::cerr) and llvm::MemoryBuffer(for input stream). And using of llvm::raw_ostream is pretty easy but for me learning of how to use llvm::MemoryBuffer is pretty much difficult. I found a good sample code; utils/yaml2obj/yaml2obj.cpp. The function, main() in

On Thu, Sep 24, 2009 at 2:32 PM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 24, 2009, at 1:23 PM, OvermindDL1 wrote: > >> I was writing something using MemoryBuffer, and while looking through >> its code I came across line 59: >> assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); >> I am curious if the MemoryBuffer

Hi Justin Holewinski, >> As far as I know, there is not a good way to implement user prompts with the LLVM APIs. This info helps me a lot. I tried to do a thing that is not possible. Thank you very much. Sincerely Journeyer 2013/1/15 Justin Holewinski <justin.holewinski at gmail.com>: > Is this for user prompts, or just reading data from stdin? You can use >

I mad the change, and still have the problem. I investigate more the source code of llvm. First, I change isRawBitcode function to print the content of the parameter like this: original: http://llvm.org/docs/doxygen/html/ReaderWriter_8h_source.html#l00081 inline bool isRawBitcode(const unsigned char *BufPtr, const unsigned char *BufEnd) { // These bytes sort

And for this kind of question I think I would better hold in. There would be more important issue worth on this list. For this reason I am sorry. Sincerely Journeyer 2013/1/15 Journeyer J. Joh <oosaprogrammer at gmail.com>: > Hi Justin Holewinski, > >>> As far as I know, there is not a good way to implement user prompts with the LLVM APIs. > > This info helps me a

In MemoryBuffer::init, we have an assert that reads the memory at `BufEnd`, which is one past the end of some memory region: from lib/Support/MemoryBuffer.cpp:45: > void MemoryBuffer::init(const char *BufStart, const char *BufEnd, > bool RequiresNullTerminator) { > assert((!RequiresNullTerminator || BufEnd[0] == 0) && > "Buffer is not

Is this for user prompts, or just reading data from stdin? You can use MemoryBuffer::getSTDIN to read the contents of stdin into a memory buffer. Then you can get the data pointer and size and read it in. As far as I know, there is not a good way to implement user prompts with the LLVM APIs. On Mon, Jan 14, 2013 at 4:57 AM, Journeyer J. Joh <oosaprogrammer at gmail.com>wrote: >

On 12/2/2014 11:19 PM, Rui Ueyama wrote: > Do you have to know whether a MemoryBuffer was in a library or not during > parsing that MemoryBuffer? Yes, I need to know that while parsing the buffer too. > > If not, we could just set a library name to a File in > FileArchive::instantiateMember after we call _registry.parseFile. > > On Tue, Dec 2, 2014 at 9:08 PM, Shankar Easwaran

On Thu, Sep 24, 2009 at 4:26 PM, Gordon Henriksen <gordonhenriksen at me.com> wrote: > NUL-termination is an optimization, in particular for clang's parser, > where it's cheaper to check for '\0' to signal EOF than it is to > compare pointers. Its presence doesn't move the end iterator (just > makes it dereference-able) and in no way impacts your ability to

On 03/16/2017 06:22 PM, Mehdi Amini via llvm-dev wrote: >> On Mar 16, 2017, at 10:29 AM, Roger Ferrer Ibanez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm implementing interleaved source in assembly output. Early reviews raised the concern > Is there a patch up for review? https://reviews.llvm.org/D30898

Hi guys, In porting our project over to LLVM-2.8 today I ran into a change that should probably go in the 2.8 release notes. After r100485, the MemoryBuffer::getMemBuffer went from: /// getMemBuffer - Open the specified memory range as a MemoryBuffer. Note /// that EndPtr[0] must be a null byte and be accessible!

MemoryBuffer requires that its buffer be NULL terminated. This is handy for some users, but it is a hard requirement for some cases. For example, currently I get the following valgrind error when doing LTO and fetching an archive member: at 0x6DAC36E: llvm::MemoryBuffer::init(char const*, char const*) (MemoryBuffer.cpp:50) Address 0x5fecea0 is 0 bytes after a block of size 464 alloc'd

make[4]: Entering directory `/usr/local/src/llvm-2.7/tools/clang/lib/Basic' llvm[4]: Compiling Builtins.cpp for Release build llvm[4]: Compiling ConvertUTF.c for Release build llvm[4]: Compiling Diagnostic.cpp for Release build llvm[4]: Compiling FileManager.cpp for Release build llvm[4]: Compiling IdentifierTable.cpp for Release build llvm[4]: Compiling SourceLocation.cpp for Release build