search for: dataextractor

Hi Ben, Me and David were discussing ways to use DataExtractor recently and I found one thing in the comments that seems wrong. >From include/llvm/Support/DataExtractor.h: 336 /// Test the validity of \a offset. 337 /// 338 /// @return 339 /// \b true if \a offset is a valid offset into the data in this 340 /// object, \b false otherwise....

...ract this from the container (ObjectFile >> + // provides this information). This problem is fixed in DWARFv4 >> + // See this dwarf-discuss discussion for more details: >> + // http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2011-December/001173.html >> + DataExtractor debugFrameData(getDebugFrameSection(), isLittleEndian(), >> + getAddressSize()); >> + DebugFrame.reset(new DWARFDebugFrame()); >> + DebugFrame->parse(debugFrameData); >> + return DebugFrame.get(); >> +} >> + >> const DW...

...StringRef rangeSection = StringRef()); + StringRef rangeSection = StringRef(), + const RelocAddrMap &Map = RelocAddrMap()); virtual void dump(raw_ostream &OS) = 0; diff --git a/include/llvm/Support/DataExtractor.h b/include/llvm/Support/DataExtractor.h index 8d880fd..a3ae782 100644 --- a/include/llvm/Support/DataExtractor.h +++ b/include/llvm/Support/DataExtractor.h @@ -10,6 +10,7 @@ #ifndef LLVM_SUPPORT_DATAEXTRACTOR_H #define LLVM_SUPPORT_DATAEXTRACTOR_H +#include "llvm/ADT/DenseMap.h" #in...

...ivate::Thread&, unsigned int, lldb_private::RegisterInfoInterface*) () from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7 #2 0x00007f81cc153a24 in RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&, lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&) () from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7 #3 0x00007f81cc151e5e in ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) () from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7 #4 0x00007f81cc1523b3 in T...

On 28/01/2020 20:37, David Blaikie via llvm-dev wrote: > and one idea I had was to have the DWARFDataExtractor return a new > DWARFDataExtractor that was specifically bounded to the parsed length > for this reason. I think this would be great. In fact, I was getting ready to propose something like that myself. :) FWIW, lldb DataExtractors already support this kind of slicing. pl

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

...ARF/DWARFDebugLine.h:27:7: note: > candidate constructor (the implicit default constructor) not viable: > requires 0 arguments, but 1 was provided > /home/yawmoo/Desktop/clfs/sources/llvm/tools/lld/ELF/InputFiles.cpp:89:34: error: > no viable conversion from 'llvm::DataExtractor' to 'const > llvm::DWARFDataExtractor' > DwarfLine->getOrParseLineTable(LineData, 0); > ^~~~~~~~ > /home/yawmoo/Desktop/clfs/sources/llvm/include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h:20:7: note: > candidate constructo...

...me background: A while back while working on code to read / write PDB files, I came up with Yet Another Stream Abstraction. Note that LLVM already has a few. Off the top of my head, theres: 1) `MemoryBuffer` and its associated class hierarchy 2) `raw_ostream` and it's associated classes. 3) `DataExtractor` which is used for reading from a StringRef. There's probably more, and indivdiual subprojects might have even created their own. The reason I couldn't use any of these and needed to invent another is because PDB files are not laid out contiguously in memory. You can think of it as a fil...

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? >

...gnoring the table and then continuing from the next. With my latest changes, the parser continues reading the header until the actual end for the file format, even if that goes beyond the claimed header end, reporting a warning if it does so, and filling in zeroes if it runs out of data, as per the DataExtractor API. The parser then starts parsing the body from the claimed header end until the unit length is reached. This provides us with maximum possible information (useful for dumpers), but still with the ability to stop (useful for things where correctness is more important). > > >> This w...

...arrowly useful stuff" > > Broadly useful stuff: > AlignOf > Allocator > ArrayRecycler > Atomic > AtomicOrdering > Capacity > Casting > Chrono > circular_raw_ostream > COM.h > CommandLine.h > Compiler.h > ConvertUTF.h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h &g...

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

...(and its subprojects)". > Broadly useful stuff: > AlignOf > Allocator > ArrayRecycler > Atomic > AtomicOrdering > Capacity > Casting > Chrono > circular_raw_ostream > COM.h > CommandLine.h > Compiler.h > ConvertUTF.h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h &g...

...MakeFiles/LLVMSupport.dir/COM.cpp.o CMakeFiles/LLVMSupport.dir/CommandLine.cpp.o CMakeFiles/LLVMSupport.dir/Compression.cpp.o CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o CMakeFiles/LLVMSupport.dir/ConvertUTFWrapper.cpp.o CMakeFiles/LLVMSupport.dir/CrashRecoveryContext.cpp.o CMakeFiles/LLVMSupport.dir/DataExtractor.cpp.o CMakeFiles/LLVMSupport.dir/DataStream.cpp.o CMakeFiles/LLVMSupport.dir/Debug.cpp.o CMakeFiles/LLVMSupport.dir/DeltaAlgorithm.cpp.o CMakeFiles/LLVMSupport.dir/DAGDeltaAlgorithm.cpp.o CMakeFiles/LLVMSupport.dir/Dwarf.cpp.o CMakeFiles/LLVMSupport.dir/Error.cpp.o CMakeFiles/LLVMSupport.dir/ErrorH...

.... carl at carl:~/Downloads/llvm3.0/llvm$ svn status ? include/llvm/Support/DataTypes.h carl at carl:~/Downloads/llvm3.0/llvm$ make -j 4 make[1]: Entering directory `/home/carl/Downloads/llvm3.0/llvm/lib/Support' llvm[1]: Compiling CommandLine.cpp for Debug+Asserts build llvm[1]: Compiling DataExtractor.cpp for Debug+Asserts build llvm[1]: Compiling Debug.cpp for Debug+Asserts build llvm[1]: Compiling DeltaAlgorithm.cpp for Debug+Asserts build llvm[1]: Compiling Disassembler.cpp for Debug+Asserts build In file included from CommandLine.cpp:25: /home/carl/Downloads/llvm3.0/llvm/include/llvm/Support...

...while working on code to read / write PDB files, I came up > with Yet Another Stream Abstraction. Note that LLVM already has a few. > Off the top of my head, theres: > > 1) `MemoryBuffer` and its associated class hierarchy > 2) `raw_ostream` and it's associated classes. > 3) `DataExtractor` which is used for reading from a StringRef. > > There's probably more, and indivdiual subprojects might have even created > their own. > > The reason I couldn't use any of these and needed to invent another is > because PDB files are not laid out contiguously in memory....

Hi all, Since December, I've made several changes to the DWARF debug line parser to improve its error handling. Some examples include removing redundant error checks[1] and making address size mismatches non-fatal to parsing[2], with several more about to land or being planned. David Blaikie recommended I post something to give a bit more context to these changes. I am a member of Sony's

...ease+Asserts build llvm[1]: Compiling ConvertUTF.c for Release+Asserts build llvm[1]: Compiling ConvertUTFWrapper.cpp for Release+Asserts build llvm[1]: Compiling CrashRecoveryContext.cpp for Release+Asserts build llvm[1]: Compiling DAGDeltaAlgorithm.cpp for Release+Asserts build llvm[1]: Compiling DataExtractor.cpp for Release+Asserts build llvm[1]: Compiling DataStream.cpp for Release+Asserts build llvm[1]: Compiling Debug.cpp for Release+Asserts build llvm[1]: Compiling DeltaAlgorithm.cpp for Release+Asserts build llvm[1]: Compiling Dwarf.cpp for Release+Asserts build llvm[1]: Compiling DynamicLibrary.c...