search for: memoryobject

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by chang...

...en proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > > BitstreamReader is the only in-tree client of the DataStreamer and > MemoryObject interfaces. In practice when using user-facing LLVM tools, the > bitcode will normally either be in memory or in a file, so the best way to > access it is through memory, either directly or memory mapped. > > As part of some refactorings I am making to BitstreamReader, I would like >...

...ttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html > > On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> > wrote: >> >> Hi all, >> >> BitstreamReader is the only in-tree client of the DataStreamer and >> MemoryObject interfaces. In practice when using user-facing LLVM tools, the >> bitcode will normally either be in memory or in a file, so the best way to >> access it is through memory, either directly or memory mapped. >> >> As part of some refactorings I am making to BitstreamReader, I...

...that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I still see a lot of std::endl's etc. >> 3. In include/llvm/Support/MemoryObject.h, you changed all >> "uintptr_t" to "uint64_t". Is there a good reason for this? If not, >> please change them back.' > > Yes, there is. If you're disassembling in a memory space that's > larger than yours (for example, on a computer wher...

...thinking about maybe making them saturate, but honestly if we run out of space we should simply break and allow the developer to make the Indenter bigger. Maybe we should have another argument to the constructor specifying how large the buffer should be...? > 3. In include/llvm/Support/MemoryObject.h, you changed all > "uintptr_t" to "uint64_t". Is there a good reason for this? If not, > please change them back.' Yes, there is. If you're disassembling in a memory space that's larger than yours (for example, on a computer where LLVM is built 32- b...

Hi, I have a simple program example attached. All it does is try to derive a class from llvm::MemoryObject. Can anyone tell me why this fails to compile with this error message: clang -DHAVE_CONFIG_H -I. -I../src -I../include -I../test -I/usr/include/llvm-c-3.2 -I/usr/include/llvm-3.2 -O0 -g3 -Wall -O0 -Wall -g3 -MT mem.o -MD -MP -MF .deps/mem.Tpo -c -o mem.o mem.cpp mv -f .deps/mem.Tpo .deps/mem.Po...

...DEBUG raw_ostream &DebugOut = DebugFlag ? dbgs() : nulls(); #else @@ -244,22 +247,22 @@ static void DisassembleObject(const ObjectFile *Obj) { #endif for (Index = Start; Index < End; Index += Size) { MCInst Inst; - if (DisAsm->getInstruction(Inst, Size, memoryObject, Index, + outs() << format("%8x:\t", Index); + if (DisAsm->getInstruction(Inst, Size, memoryObject, Index - SectionVMA, DebugOut, nulls())) { - uint64_t addr; - if (error(i->getAddress(addr))) break; -...

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

...iff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the abstract base class MCDisassembler (llvm/ MC/MCDisassembler.h). The disassembler is documented in detail in – - lib/Target/X86/X86Disassembler.h (disassembler runtime) - utils/TableGen/X86DisassemblerEmitter.h (table emitter) – as well as in the...

...fied region, printing the disassembled instruction to the > specified raw_ostream, and returning the size of the instruction in > bytes. On error, this returns zero and fills in ErrorInfo with a > human readable description of the error. > virtual unsigned DisassembleInstruction(MemoryObject &region, > raw_ostream &OS, std::string &ErrorInfo) = 0; > > } > > Having this sort of stateless API means that higher level clients > (which are stateful) can be built on top of them without adding > overhead to clients who don't care about the state. &g...

...le-driven disassembler for the X86 > architecture (16-, 32-, and 64-bit incarnations), integrated into > the MC framework. The disassembler is table-driven, using a custom > TableGen backend to generate hierarchical tables optimized for fast > decode. The disassembler consumes MemoryObjects and produces arrays > of MCInsts, adhering to the abstract base class MCDisassembler (llvm/ > MC/MCDisassembler.h). > > The disassembler is documented in detail in > – > - lib/Target/X86/X86Disassembler.h (disassembler runtime) > - utils/TableGen/X86DisassemblerEmitter.h (t...

Hi All, I am trying to build llvm on AIX. I installed all the required packages including gcc, g++, etc ./configure also went fine. but i tried to run gmake, i got the following error: llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build llvm[1]: Compiling Mutex.cpp for Release+Asserts build llvm[1]: Compiling Path.cpp for Release+Asserts build In file included from Path.cpp:289:0: Unix/Path.inc: In static member function 'static llvm::sys::Path llvm::sys::Path::GetMainExecutable(const char*, void*...

..., > > I am trying to build llvm on AIX. I installed all the required packages > including gcc, g++, etc > ./configure also went fine. but i tried to run gmake, i got the following > error: > > llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build > llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build > llvm[1]: Compiling Mutex.cpp for Release+Asserts build > llvm[1]: Compiling Path.cpp for Release+Asserts build > In file included from Path.cpp:289:0: > Unix/Path.inc: In static member function 'static llvm::sys::Path > llvm::sys::Path::GetMainExec...

...g/pipermail/llvm-dev/2016-October/106640.html), [moving block info block state](http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html), [APIs for bitcode files containing multiple modules](http://lists.llvm.org/pipermail/llvm-dev/2016-October/106492.html), [removing the DataStreamer and MemoryObject interfaces](http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html), and finally [a more detailed design for ThinLTO and vcall CFI](http://lists.llvm.org/pipermail/llvm-dev/2016-October/106490.html). * Dehao Chen has started an RFC on [retaining profile accuracy in the face of code dupl...

...CMakeFiles/LLVMSupport.dir/LineIterator.cpp.o CMakeFiles/LLVMSupport.dir/Locale.cpp.o CMakeFiles/LLVMSupport.dir/LockFileManager.cpp.o CMakeFiles/LLVMSupport.dir/ManagedStatic.cpp.o CMakeFiles/LLVMSupport.dir/MathExtras.cpp.o CMakeFiles/LLVMSupport.dir/MemoryBuffer.cpp.o CMakeFiles/LLVMSupport.dir/MemoryObject.cpp.o CMakeFiles/LLVMSupport.dir/MD5.cpp.o CMakeFiles/LLVMSupport.dir/Options.cpp.o CMakeFiles/LLVMSupport.dir/PluginLoader.cpp.o CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o CMakeFiles/LLVMSupport.dir/RandomNumberGenerator.cpp.o CMakeFiles/LLVMSupport.dir/Regex.cpp.o CMakeFiles/LLVMSupport.di...

...mode is used in tree only by llvm-dis, which means that > some bugs can hide for quite some time (222505 for example). To the > best of my knowledge it is only real user is PNaCl. > > It also has a disproportional code complexity. There are two virtual > interfaces (DataStreamer and MemoryObject) and they are leaky: Not all > bitcode features are supported when streaming and there are a few "if > (LazyStreamer)" int the reader. > > I have attached two patches that solve the problem with different trade-offs. > > One just deletes the feature. This would make P...

...rvalMap.cpp for Release build llvm[1]: Compiling IsInf.cpp for Release build llvm[1]: Compiling IsNAN.cpp for Release build llvm[1]: Compiling ManagedStatic.cpp for Release build llvm[1]: Compiling Memory.cpp for Release build llvm[1]: Compiling MemoryBuffer.cpp for Release build llvm[1]: Compiling MemoryObject.cpp for Release build llvm[1]: Compiling Mutex.cpp for Release build llvm[1]: Compiling Path.cpp for Release build llvm[1]: Compiling PathV2.cpp for Release build llvm[1]: Compiling PluginLoader.cpp for Release build llvm[1]: Compiling PrettyStackTrace.cpp for Release build llvm[1]: Compiling Proce...

...ng IsInf.cpp for Release+Asserts build llvm[1]: Compiling IsNAN.cpp for Release+Asserts build llvm[1]: Compiling ManagedStatic.cpp for Release+Asserts build llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build llvm[1]: Compiling PluginLoader.cpp for Release+Asserts build llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build llvm[1]: Compiling PrettyStackTrace.cpp for Release+Asserts build llvm[1]: Compiling Regex.cpp for Release+Asserts build llvm[1]: Compiling SmallPtrSet.cpp for Release+Asserts build llvm[1]: Compiling SmallVector.cpp for Release+Asserts build llvm[1]: Compiling SourceM...

...Asserts build > llvm[1]: Compiling IsNAN.cpp for Release+Asserts build > llvm[1]: Compiling ManagedStatic.cpp for Release+Asserts build > llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build > llvm[1]: Compiling PluginLoader.cpp for Release+Asserts build > llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build > llvm[1]: Compiling PrettyStackTrace.cpp for Release+Asserts build > llvm[1]: Compiling Regex.cpp for Release+Asserts build > llvm[1]: Compiling SmallPtrSet.cpp for Release+Asserts build > llvm[1]: Compiling SmallVector.cpp for Release+Asserts build > l...

....8/include/llvm/Support/MachO.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/ManagedStatic.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MathExtras.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MemoryBuffer.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MemoryObject.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/MutexGuard.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/NoFolder.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/OutputBuffer.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/PassNameParser.h -- Installing: /u...