search for: leb128

...Personally I would prefer to land the initial version without touching the ELF/COFF backends and refactor in a second pass. > - I can imagine that you would eventually want to support two modes of wasm > object files. In one form, object files are represented in the compact > format using LEB128 encoding, and the linker has to decode and re-encode > LEB128 instruction streams. In the other form, they are still in LEB128 but > uses full 5 bytes for 4-byte numbers, so that you can just concatenate them > without decoding/re-encoding. Which mode do you want to make default? The >...

Dan Gohman <sunfish at mozilla.com> writes: >> Sorry, I meant why that didn't work with ELF (or what else didn't). >> > > The standard executable WebAssembly format does not use ELF, for numerous > reasons, most visibly that ELF is designed for sparse decoding -- headers > contain offsets to arbitrary points in the file, while WebAssembly's format > is

...DAR->Message += "Processing "; DAR->Message += F.getName(); DAR->Message += "\n"; } AsmPrinter ---------- We dump the messages from DumpAccumulator into a section called ".llvm_dump" in a compressed manner. Specifically, the section contains: - LEB128 encoding of the original size in bytes - LEB128 encoding of the compressed size in bytes - the message compressed by zlib::compressed in that order. llvm-readobj ------------ We read the .llvm_dump section. We dump each chunk of compressed data one after another. Existing Implementation ======...

...a section containing metadata on function stack sizes. We use this to measure changes to stack size between versions of the compiler and it also allows our licensees to do the same for their code. The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). We would like to upstream this change as a PS4 only modification, or as a more general cross platform one. Would people be interested in (or happy with) such a patch, target specific or otherwise? Thanks, Sean Eveson SN Systems - Sony Interactive Entertainment -------------- next part -...

...R->Message += "\n"; >>    } >> >> AsmPrinter >> ---------- >> >> We dump the messages from DumpAccumulator into a section called >> ".llvm_dump" in a compressed manner.  Specifically, the section >> contains: >> >> - LEB128 encoding of the original size in bytes >> - LEB128 encoding of the compressed size in bytes >> - the message compressed by zlib::compressed >> >> in that order. >> >> llvm-readobj >> ------------ >> >> We read the .llvm_dump section.  We dump ea...

...clude "llvm/Support/DataTypes.h" #include "llvm/Support/Debug.h" #include "llvm/Support/Error.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/Format.h" #include "llvm/Support/FormattedStream.h" #include "llvm/Support/LEB128.h" #include "llvm/Support/LowLevelTypeImpl.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/MathExtras.h" #include "llvm/Support/MemoryBuffer.h" #include "llvm/Support/PrettyStackTrace.h" #include "llvm/Support/Regex.h&quo...

...sage += "\n"; > > } > > > > AsmPrinter > > ---------- > > > > We dump the messages from DumpAccumulator into a section called > > ".llvm_dump" in a compressed manner. Specifically, the section > > contains: > > > > - LEB128 encoding of the original size in bytes > > - LEB128 encoding of the compressed size in bytes > > - the message compressed by zlib::compressed > > > > in that order. > > > > llvm-readobj > > ------------ > > > > We read the .llvm_dump section. W...

...ePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetS...

...tion of the format of the profile > data file. > > The Clang user guide here describes it as an ASCII text file: > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > Whereas the posts above and the referenced link describe it as a stream of > bytes containing LEB128s: > http://www.llvm.org/docs/CoverageMappingFormat.html > > From experimenting with the latest trunk I can see the latter is correct > (well, at least the file I get is not ASCII text). > Should we update the Clang user guide documentation? > Or am I just getting confused? Are the...

...ePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h > ELF.h > GCOV.h > GenericDomTree.h > GenericDomTreeConstruction.h > GraphWriter.h > LEB128.h > LEB128.h seems quite generic. > LockFileManager.h > LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetPars...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...bit confused about the documentation of the format of the profile data file. The Clang user guide here describes it as an ASCII text file: http://clang.llvm.org/docs/UsersManual.html#sample-profile-format Whereas the posts above and the referenced link describe it as a stream of bytes containing LEB128s: http://www.llvm.org/docs/CoverageMappingFormat.html >From experimenting with the latest trunk I can see the latter is correct (well, at least the file I get is not ASCII text). Should we update the Clang user guide documentation? Or am I just getting confused? Are there two formats, one used...

...nclude "llvm/Support/Debug.h" >> #include "llvm/Support/Error.h" >> #include "llvm/Support/ErrorHandling.h" >> #include "llvm/Support/Format.h" >> #include "llvm/Support/FormattedStream.h" >> #include "llvm/Support/LEB128.h" >> #include "llvm/Support/LowLevelTypeImpl.h" >> #include "llvm/Support/ManagedStatic.h" >> #include "llvm/Support/MathExtras.h" >> #include "llvm/Support/MemoryBuffer.h" >> #include "llvm/Support/PrettyStackTrace.h&...

...>>>> #include "llvm/Support/Error.h" >>>> #include "llvm/Support/ErrorHandling.h" >>>> #include "llvm/Support/Format.h" >>>> #include "llvm/Support/FormattedStream.h" >>>> #include "llvm/Support/LEB128.h" >>>> #include "llvm/Support/LowLevelTypeImpl.h" >>>> #include "llvm/Support/ManagedStatic.h" >>>> #include "llvm/Support/MathExtras.h" >>>> #include "llvm/Support/MemoryBuffer.h" >>>> #includ...

...gt; data file. > > > > The Clang user guide here describes it as an ASCII text file: > > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > > > Whereas the posts above and the referenced link describe it as a stream > of > > bytes containing LEB128s: > > http://www.llvm.org/docs/CoverageMappingFormat.html > > > > From experimenting with the latest trunk I can see the latter is correct > > (well, at least the file I get is not ASCII text). > > Should we update the Clang user guide documentation? > > Or am I...

...ypes.h" > #include "llvm/Support/Debug.h" > #include "llvm/Support/Error.h" > #include "llvm/Support/ErrorHandling.h" > #include "llvm/Support/Format.h" > #include "llvm/Support/FormattedStream.h" > #include "llvm/Support/LEB128.h" > #include "llvm/Support/LowLevelTypeImpl.h" > #include "llvm/Support/ManagedStatic.h" > #include "llvm/Support/MathExtras.h" > #include "llvm/Support/MemoryBuffer.h" > #include "llvm/Support/PrettyStackTrace.h" > #include...

...pport/Debug.h" >>> #include "llvm/Support/Error.h" >>> #include "llvm/Support/ErrorHandling.h" >>> #include "llvm/Support/Format.h" >>> #include "llvm/Support/FormattedStream.h" >>> #include "llvm/Support/LEB128.h" >>> #include "llvm/Support/LowLevelTypeImpl.h" >>> #include "llvm/Support/ManagedStatic.h" >>> #include "llvm/Support/MathExtras.h" >>> #include "llvm/Support/MemoryBuffer.h" >>> #include "llvm/Support...

...> > The Clang user guide here describes it as an ASCII text file: > > http://clang.llvm.org/docs/UsersManual.html#sample-profile-format > > > > Whereas the posts above and the referenced link describe it as a stream > of > > bytes containing LEB128s: > > http://www.llvm.org/docs/CoverageMappingFormat.html > > > > From experimenting with the latest trunk I can see the latter is correct > > (well, at least the file I get is not ASCII text). > > Should we update the Clang user guide documentation...

On 04/29/2013 15:53, Keith Walker wrote: > It sounds like you are trying to load the DWARF sections into target memory .... and if so I guess I would have to ask you why as they are not normally loaded into target memory? You are right, debug sections aren't normally loaded into the memory together with the sections needed for running. However, I am mostly focusing on the (lightweight)

...p.o CMakeFiles/LLVMSupport.dir/GraphWriter.cpp.o CMakeFiles/LLVMSupport.dir/Hashing.cpp.o CMakeFiles/LLVMSupport.dir/IntEqClasses.cpp.o CMakeFiles/LLVMSupport.dir/IntervalMap.cpp.o CMakeFiles/LLVMSupport.dir/IntrusiveRefCntPtr.cpp.o CMakeFiles/LLVMSupport.dir/JamCRC.cpp.o CMakeFiles/LLVMSupport.dir/LEB128.cpp.o 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/LLVMSuppor...