search for: getbufferstart

...sed in terminator type, fully optimized for all situations. Policy based trumps hand-rolled trumps generic in terms of speed for all situations. I write code like that all the time, would be quite simple, would you accept such code? Just from a quick thought the interface would change from using getBufferStart()/getBufferEnd()/getBufferSize() to something like getRange() which returns a random_access_range_type<no_policy>, which would probably have an equivalent use like (using a monotype font to line things up): typedef const char cchar; MemoryBuffer mb; MemoryBuffer::range_type<policy> rt(...

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 llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has different visibility (1) in /usr/local/lib/libLLVMSupport.a...

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 /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and > (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has > different visibility (1) in > /usr/l...

...th, size_t size, > + OwningPtr<FileOutputBuffer> &result, > + unsigned flags=0); Arguments should start with an upper case letter. (same for all of these) > + /// Returns a pointer to the start of the buffer. > + uint8_t *getBufferStart() const { > + return bufferStart; > + } > + > + /// Returns a pointer to the end of the buffer. > + uint8_t *getBufferEnd() const { > + return bufferEnd; > + } > + > + /// Returns size of the buffer. > + size_t getBufferSize() const { > + return buffe...

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:

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

...rectly with some kinds of garbage (in // particular, it will work if the bitcode file is followed by zeros, or if // it's followed by another bitcode file). size_t GetBitcodeSize(MemoryBufferRef Buffer) { const unsigned char *BufPtr = reinterpret_cast<const unsigned char *>(Buffer.getBufferStart()); const unsigned char *EndBufPtr = reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); if (isBitcodeWrapper(BufPtr, EndBufPtr)) { const unsigned char *FixedBufPtr = BufPtr; if (SkipBitcodeWrapperHeader(FixedBufPtr, EndBufPtr, true)) report_fatal_error(&qu...

...rs mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > I like it in general. The only comment I have is that it should match the MemoryBuffer interface where possible. static error_code getFile(...); const char *getBufferStart() const; const char *getBufferEnd() const; size_t getBufferSize() const; StringRef getBuffer() const; const char *getBufferIdentifier() const; - Michael Spencer

...u http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > I like it in general. The only comment I have is that it should match > the MemoryBuffer interface where possible. > > static error_code getFile(...); > > const char *getBufferStart() const; > const char *getBufferEnd() const; > size_t getBufferSize() const; > StringRef getBuffer() const; > const char *getBufferIdentifier() const; Except that MemoryBuffer is about reading which is "getting". OutputBuffer is about writing, so the "get" part...

...>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> I like it in general. The only comment I have is that it should match >> the MemoryBuffer interface where possible. >> >> static error_code getFile(...); >> >> const char *getBufferStart() const; >> const char *getBufferEnd() const; >> size_t getBufferSize() const; >> StringRef getBuffer() const; >> const char *getBufferIdentifier() const; > > Except that MemoryBuffer is about reading which is "getting". OutputBuffer is about writing, so th...

...sLeftToReadInStream, >> static_cast<uint32_t>(SB->BlockSize)); >> + uint32_t BytesToReadInBlock = (std::min)( >> + BytesLeftToReadInStream, static_cast<uint32_t>(SB->BlockSize)); >> auto StreamBlockData = >> StringRef(M.getBufferStart() + StreamBlockOffset, >> BytesToReadInBlock); >> if (auto EC = checkOffset(M, StreamBlockData)) >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at lists.llvm.org >> http://lists.llvm.org/cg...

...icular, it will work if the bitcode file is followed by zeros, or >> if >> // it's followed by another bitcode file). >> size_t GetBitcodeSize(MemoryBufferRef Buffer) { >> const unsigned char *BufPtr = >> reinterpret_cast<const unsigned char *>(Buffer.getBufferStart()); >> const unsigned char *EndBufPtr = >> reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); >> if (isBitcodeWrapper(BufPtr, EndBufPtr)) { >> const unsigned char *FixedBufPtr = BufPtr; >> if (SkipBitcodeWrapperHeader(FixedBufPtr, E...

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

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

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 >

...e 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 garbage). I would suggest that you put a watchpoint on mbjit->getBufferStart() and single step your program to make sure it is not freed, over written somewhere. thx Vikas. ======= On Thu, Mar 20, 2014 at 7:50 AM, Willy WOLFF <willy.wolff at etu.unistra.fr>wrote: > The stack trace is: > (gdb) bt > #0 0x00000000004fa8c8 in llvm::BitstreamCursor::Read(uns...

Currently a power failure or other hard crash can cause lld leave a temporary file around. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

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