0bf2d699067d434fe3dd187caf526ff94f19494f |
|
23-Jul-2013 |
Ed Maste <emaste@freebsd.org> |
elf-core: Parse vendor-specific notes ELF notes contain a 'name' field, which specifies a vendor who defines the format of the note. Examples are 'FreeBSD' or 'GNU', or it may be empty for generic notes. Add a case for FreeBSD-specific notes, leaving Linux and GNU notes, other vendor-specific notes, and generic notes to be handled by the existing code for now. Thanks to Samuel Jacob for reviewing and suggesting improvements. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186973 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
d4f95f3c9462a977f8c15c5062d30bf62cd49110 |
|
29-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11730263> PC relative loads are missing disassembly comments when disassembled in a live process. This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually. The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178315 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
4bc40781466dd9d2de0d51fec5feb342ea45e87f |
|
21-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
Fixed the ValidOffsetForDataOfSize() to use simpler logic. Fixed DataExtractor::BytesLeft() to return the correct value. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177616 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
940ca9447d84a08883d2ce77a765475f09243fc5 |
|
08-Feb-2013 |
Greg Clayton <gclayton@apple.com> |
Fixed 2 more issues found by the address sanitizer: 1 - A store off the end of a buffer in ValueObject.cpp 2 - DataExtractor had cases where bad offsets could cause invalid memory to be accessed. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174757 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
36da2aa6dc5ad9994b638ed09eb81c44cc05540b |
|
25-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13069948> Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
0fea0512e47d1820dd78de2748b874c81eea77d6 |
|
30-Dec-2011 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10368163> Watch for empty symbol tables by doing a lot more error checking on all mach-o symbol table load command values and data that is obtained. This avoids a crash that was happening when there was no string table. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147358 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
24a6bd9835ed1655984397b0cdf35127e47681e9 |
|
27-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Added support for the new ".apple_objc" accelerator tables. These tables are in the same hashed format as the ".apple_names", but they map objective C class names to all of the methods and class functions. We need to do this because in the DWARF the methods for Objective C are never contained in the class definition, they are scattered about at the translation unit level and they don't even have attributes that say the are contained within the class itself. Added 3 new formats which can be used to display data: eFormatAddressInfo eFormatHexFloat eFormatInstruction eFormatAddressInfo describes an address such as function+offset and file+line, or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants). The format character for this is "A", the long format is "address". eFormatHexFloat will print out the hex float format that compilers tend to use. The format character for this is "X", the long format is "hex float". eFormatInstruction will print out disassembly with bytes and it will use the current target's architecture. The format character for this is "i" (which used to be being used for the integer format, but the integer format also has "d", so we gave the "i" format to disassembly), the long format is "instruction". Mate the lldb::FormatterChoiceCriterion enumeration private as it should have been from the start. It is very specialized and doesn't belong in the public API. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143114 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
915448044bac6fdac22a33cc46697dcb771a8df2 |
|
06-Sep-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139160 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
37f962e785be99dc4f0c5e9d02416992ff03bbd0 |
|
22-Aug-2011 |
Greg Clayton <gclayton@apple.com> |
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
8d2ea2888a4acb7f140f9af64ddd2b16b2dee870 |
|
17-Jul-2011 |
Greg Clayton <gclayton@apple.com> |
Added a boolean to the pure virtual lldb_private::Process::CanDebug(...) method so process plug-ins that are requested by name can answer yes when asked if they can debug a target that might not have any file in the target. Modified the ConnectionFileDescriptor to have both a read and a write file descriptor. This allows us to support UDP, and eventually will allow us to support pipes. The ConnectionFileDescriptor class also has a file descriptor type for each of the read and write file decriptors so we can use the correct read/recv/recvfrom call when reading, or write/send/sendto for writing. Finished up an initial implementation of UDP where you can use the "udp://" URL to specify a host and port to connect to: (lldb) process connect --plugin kdp-remote udp://host:41139 This will cause a ConnectionFileDescriptor to be created that can send UDP packets to "host:41139", and it will also bind to a localhost port that can be given out to receive the connectionless UDP reply. Added the ability to get to the IPv4/IPv6 socket port number from a ConnectionFileDescriptor instance if either file descriptor is a socket. The ProcessKDP can now successfully connect to a remote kernel and detach using the above "processs connect" command!!! So far we have the following packets working: KDP_CONNECT KDP_DISCONNECT KDP_HOSTINFO KDP_VERSION KDP_REATTACH Now that the packets are working, adding new packets will go very quickly. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135363 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
d52d00f4edb746ba458a3e659699160952dc925e |
|
16-Jul-2011 |
Greg Clayton <gclayton@apple.com> |
Completed more work on the KDP darwin kernel debugging Process plug-in. Implemented connect, disconnect, reattach, version, and hostinfo. Modified the ConnectionFileDescriptor class to be able to handle UDP. Added a new Stream subclass called StreamBuffer that is backed by a llvm::SmallVector for better efficiency. Modified the DataExtractor class to have a static function that can dump hex bytes into a stream. This is currently being used to dump incoming binary packet data in the KDP plug-in. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135338 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
82f0746880b4a6b18bcf8666670140f5b4a56791 |
|
30-May-2011 |
Greg Clayton <gclayton@apple.com> |
lldb-59. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@132304 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
061b79dbf1fefaf157d414747e98a463a0f32eda |
|
09-May-2011 |
Greg Clayton <gclayton@apple.com> |
While implementing unwind information using UnwindAssemblyInstEmulation I ran into some cleanup I have been wanting to do when reading/writing registers. Previously all RegisterContext subclasses would need to implement: virtual bool ReadRegisterBytes (uint32_t reg, DataExtractor &data); virtual bool WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0); There is now a new class specifically designed to hold register values: lldb_private::RegisterValue The new register context calls that subclasses must implement are: virtual bool ReadRegister (const RegisterInfo *reg_info, RegisterValue ®_value) = 0; virtual bool WriteRegister (const RegisterInfo *reg_info, const RegisterValue ®_value) = 0; The RegisterValue class must be big enough to handle any register value. The class contains an enumeration for the value type, and then a union for the data value. Any integer/float values are stored directly in an appropriate host integer/float. Anything bigger is stored in a byte buffer that has a length and byte order. The RegisterValue class also knows how to copy register value bytes into in a buffer with a specified byte order which can be used to write the register value down into memory, and this does the right thing when not all bytes from the register values are needed (getting a uint8 from a uint32 register value..). All RegiterContext and other sources have been switched over to using the new regiter value class. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
bdcb6abaa287df2c5f312c51d993c1d0b0cb120c |
|
26-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Enabled extra warnings and fixed a bunch of small issues. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124250 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
66ed2fbeaf588fe4105a1305f7e956dcf9fbe299 |
|
05-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115578 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
5fcff9ac1a713d5e814b4a05edef7544be470ad0 |
|
15-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
15-20% speed improvement when parsing DWARF. I used instruments to find the hotspots in our code when indexing the DWARF. A combination of using SmallVector to avoid collection allocations, using fixed form sizes when possible, and optimizing the hot loops contributed to the speedup. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113961 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
178710cd4307f3d44dc76ebd70fc7daf7ebe17c5 |
|
14-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113829 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|
24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/DataExtractor.h
|