summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-233-0/+13
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* Don't mark an LC_BUILD_VERSION as giving us a Jason Molenda2018-10-111-1/+1
| | | | | | correct version if it has a major verison 0. llvm-svn: 344275
* [lldb] rename MinOS::minor to MinOS::minor_version etc. NFCEric Liu2018-10-111-8/+8
| | | | | | | The constructor initializer minor(...)/major(...) can be confused with system macros `#define minor(...)` on some platforms. llvm-svn: 344250
* Upstreaming the BridgeOS device support and the Jason Molenda2018-10-111-19/+166
| | | | | | | | | | | | | | | LC_BUILD_VERSION load command handling - this commit is a combination of patches by Adrian Prantl and myself. llvm::Triple::BridgeOS isn't defined yet, so all references to that are currently commented out. Also update Xcode project file to build the NativePDB etc plugins. <rdar://problem/43353615> llvm-svn: 344209
* [LLDB] - Add basic support for .debug_rnglists section (DWARF5)George Rimar2018-10-102-1/+5
| | | | | | | | | This adds a basic support of the .debug_rnglists section. Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported. Differential revision: https://reviews.llvm.org/D52981 llvm-svn: 344119
* [LLDB] - Improved DWARF5 support.George Rimar2018-09-132-0/+7
| | | | | | | | | This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 llvm-svn: 342153
* Move SafeMachO from Utility to HostPavel Labath2018-09-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: One of the conclusions of the discussion on D49740 was that SafeMachO is better off in the Host module (as that's the only place which should include mach/machine.h, which is what this header is working around). Also, Utility, which is the only module which cannot include Host, should not be doing anything with object file formats. This patch implements that move, and also removes any unneded includes of that file. I've verified that MacOS still compiles after this. Reviewers: jingham, zturner, teemperor Subscribers: fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D50383 llvm-svn: 342050
* Re-instate a bit of code that was commented out in r188246 whichJason Molenda2018-09-061-8/+16
| | | | | | | | | | | | | | | | | | | | | | | reads an ObjectFileMachO's string table in one chunk. Originally this was commented out because binaries in the system's shared cache all share a mega-string table and so reading the entire mega-strtab for each binary was a performance problem. In the reinstated code, I add a check that the binary we're reading from memory is not in the shared cache (there isn't a constant in <mach-o/loader.h> for this bit yet; we hardcode the value in one other place in ObjectFileMachO alread). For binaries that we're reading out of memory that are NOT in the shared cache, reading the string table in one chunk is a big performance improvement. Also have debugserver send up the flags value for binaries in its response to the jGetLoadedDynamicLibrariesInfos request. NFC. <rdar://problem/33604496> llvm-svn: 341511
* Add a relocation for R_AARCH64_ABS32 in ObjectFileELFStephane Sezer2018-08-171-4/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: .rela.debug_info relocations are being done via ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case that iterates over the relocation type is only implemented for a few different types and `assert(false)`es over the rest. Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations Reviewers: sas, xiaobai, javed.absar, espindola Reviewed By: sas Subscribers: emaste, arichardson, kristof.beyls Differential Revision: https://reviews.llvm.org/D50369 Change by Nathan Lanza <lanza@fb.com> llvm-svn: 339974
* Fix a little thinko in generating ___lldb_unnamed_symbol symbols Jim Ingham2018-08-151-1/+2
| | | | | | | | | | | when we have only an in-memory copy of the binary. Also added a test for the generation of these symbols in the in-memory and regular cases. <rdar://problem/43160401> llvm-svn: 339833
* Misc module/dwarf logging improvementsLeonard Mosescu2018-08-071-12/+17
| | | | | | | | | | | | | | This change improves the logging for the lldb.module category to note a few interesting cases: 1. Local object file found, but specs not matching 2. Local object file not found, using a placeholder module The handling and logging for the cases wehre we fail to load compressed dwarf symbols is also improved. Differential Revision: https://reviews.llvm.org/D50274 llvm-svn: 339161
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Revert "Add a relocation for R_AARCH64_ABS32 in ObjectFileELF"Stephane Sezer2018-08-061-10/+5
| | | | | | This reverts commit f055ce7eb893cd0d17ebcfd4125018f46f983aff. llvm-svn: 339071
* Add a relocation for R_AARCH64_ABS32 in ObjectFileELFStephane Sezer2018-08-061-5/+10
| | | | | | | | | | | | | | | | | | Summary: .rela.debug_info relocations are being done via ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case that iterates over the relocation type is only implemented for a few different types and `assert(false)`es over the rest. Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations Reviewers: sas, xiaobai, peter.smith, clayborg, javed.absar, espindola Differential Revision: https://reviews.llvm.org/D49407 Change by Nathan Lanza <lanza@fb.com> llvm-svn: 339068
* UUID: Add support for arbitrary-sized module IDsPavel Labath2018-06-291-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The data structure is optimized for the case where the UUID size is <= 20 bytes (standard length emitted by the GNU linkers), but larger sizes are also possible. I've modified the string conversion function to support the new sizes as well. For standard UUIDs it maintains the traditional formatting (4-2-2-2-6). If a UUID is shorter, we just cut this sequence short, and for longer UUIDs it will just repeat the last 6-byte block as long as necessary. I've also modified ObjectFileELF to take advantage of the new UUIDs and avoid manually padding the UUID to 16 bytes. While there, I also made sure the computed UUID does not depend on host endianness. Reviewers: clayborg, lemo, sas, davide, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D48633 llvm-svn: 335963
* Move AddressClass to private enums since API doesn't provide any functions ↵Tatyana Krasnukha2018-06-272-3/+3
| | | | | | | | to manage it. This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes. llvm-svn: 335710
* Represent invalid UUIDs as UUIDs with length zeroPavel Labath2018-06-262-18/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we used an all-zero UUID for that). This meant that some valid build-ids could not be represented (it's possible however unlikely that a checksum of some file would be zero) and complicated adding support for variable length build-ids (should a 16-byte empty UUID compare equal to a 20-byte empty UUID?). This patch resolves these issues by introducing a canonical representation for an invalid UUID. The slight complication here is that some clients (MachO) actually use the all-zero notation to mean "no UUID has been set". To keep this use case working (while making it very explicit about which construction semantices are wanted), replaced the UUID constructors and the SetBytes functions with named factory methods. - "fromData" creates a UUID from the given data, and it treats all bytes equally. - "fromOptionalData" first checks the data contents - if all bytes are zero, it treats this as an invalid/empty UUID. Reviewers: clayborg, sas, lemo, davide, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D48479 llvm-svn: 335612
* Change AddressClass type from 'enum' to 'enum class'.Tatyana Krasnukha2018-06-262-52/+52
| | | | | | If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa. llvm-svn: 335599
* A little cleanup in ObjectFileMachO::GetSDKVersion. Jason Molenda2018-06-251-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | This method does one of two things: 1. finds a minimum os deployment version # in a Mach-O load command and saves the three parts in the m_sdk_version, or 2. finds no valid min os version # load command, pushes a sentinel value on the m_sdk_version vector so we don't search the same load commands multiple times. There was a little bug when we found a load command with a version of 0.0.0 - the method would not add anything to the m_sdk_version vector but would declare that a success. It would not push the sentinel value to the vector. There was code later in the method which assumed that the vector always had a sentinel value, at least, and that code could crash when this method was called back when evaluating a Swift expression. (these version #'s are fetched lazily so it wouldn't happen when the object file was parsed, only when doing an expression that needed the version #). <rdar://problem/41372699> llvm-svn: 335556
* Use llvm::VersionTuple instead of manual version marshallingPavel Labath2018-06-182-46/+18
| | | | | | | | | | | | | | | | | | Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
* [FileSpec] Make style argument mandatory for SetFile. NFCJonas Devlieghere2018-06-131-2/+2
| | | | | | | | | | | | | | | | SetFile has an optional style argument which defaulted to the native style. This patch makes that argument mandatory so clients of the FileSpec class are forced to think about the correct syntax. At the same time this introduces a (protected) convenience method to update the file from within the FileSpec class that keeps the current style. These two changes together prevent a potential pitfall where the style might be forgotten, leading to the path being updated and the style unintentionally being changed to the host style. llvm-svn: 334663
* [FileSpec] Delegate common operations to llvm::sys::pathJonas Devlieghere2018-06-131-2/+2
| | | | | | | | | | | | | | | With the recent changes in FileSpec to use LLVM's path style, it is possible to delegate a bunch of common path operations to LLVM's path helpers. This means we only have to maintain a single implementation and at the same time can benefit from the efforts made by the rest of the LLVM community. This is part one of a set of patches. There was no obvious way to split this so I just worked from top to bottom. Differential revision: https://reviews.llvm.org/D48084 llvm-svn: 334615
* Add .debug_names section glue codePavel Labath2018-06-013-0/+10
| | | | llvm-svn: 333743
* Revert "[LLDB] Support GNU-style compressed debug sections (.zdebug)"Davide Italiano2018-05-121-69/+135
| | | | | | | | | | This reverts commit r332162 as it breaks the bots (Ubuntu 14.04) with the following message: Build Command Output: objcopy: option '--compress-debug-sections' doesn't allow an argument llvm-svn: 332165
* [LLDB] Support GNU-style compressed debug sections (.zdebug)Davide Italiano2018-05-121-135/+69
| | | | | | | | Patch by Erik Welander! Differential Revision: https://reviews.llvm.org/D45628 llvm-svn: 332162
* Retrieve the deployment target when retrieving an object file's triple.Adrian Prantl2018-05-111-12/+33
| | | | | | | | | | | | Getting the deployment target can be significant information when rebuilding clang modules since availability information could depend on it. rdar://problem/40039633 Differential Revision: https://reviews.llvm.org/D46669 llvm-svn: 332067
* Add support to object files for accessing the .debug_types sectionGreg Clayton2018-05-083-0/+10
| | | | | | | | In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch Differential Revision: https://reviews.llvm.org/D46529 llvm-svn: 331777
* The on-ios-device command line lldb has an optimization whereJason Molenda2018-05-042-30/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | when it and the inferior process both have the same shared cache (a conglomeration of all libraries at the same fixed address for all processes), lldb will read data out of its own memory to speed things up. The shared cache has a UUID, so lldb currently checks that the UUID of its own shared cache matches that of the inferior. This change adds one refinement to that -- it checks that the UUID is the same and that the base address of the shared cache is the same. And only uses its local shared cache if they are both identical. This involved using a different style of SPI with dyld to get lldb's shared cache load address, but it's not especially difficult. One unattractive part of the change is that I'm using the real underlying types of task_t and kern_return_t instead of picking them up from mach/mach.h. The defines that get picked up there (a lot from machine.h but others too) conflict with llvm/Support/MachO.h even when I have mach.h included before our SafeMachO.h which undefines most of the defines before including llvm/Support/MachO.h. I'll need to augment the #undefs in SafeMachO.h to get this to compile cleanly, but that'll be another day. <rdar://problem/39868238> llvm-svn: 331497
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-023-25/+26
| | | | | | | | | | | | | | This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments. This patch also reflows the paragraphs in all doxygen comments. See also https://reviews.llvm.org/D46290. Differential Revision: https://reviews.llvm.org/D46321 llvm-svn: 331373
* Reflow paragraphs in comments.Adrian Prantl2018-04-305-587/+459
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* ObjectFileELF: Add support for arbitrarily named code sectionsPavel Labath2018-04-301-0/+10
| | | | | | | | | | | | | | | | | | | ObjectFileELF assumes that code section has ".text" name. There is an exception for kalimba toolchain that can use arbitrary names, but other toolchains also could use arbitrary names for code sections. For example, corert uses separate section for compiled managed code. As lldb doesn't recognize such section it leads to problem with breakpoints on arm, because debugger cannot determine instruction set (arm/thumb) and uses incorrect breakpoint opcode that breaks program execution. This change allows debugger to correctly handle such code sections. We assume that section is a code section if it has SHF_EXECINSTR flag set and has SHT_PROGBITS type. Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>. Differential Revision: https://reviews.llvm.org/D44998 llvm-svn: 331173
* Support reading section ".gnu_debugaltlink"Jan Kratochvil2018-04-292-0/+4
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
* Always normalize FileSpec paths.Greg Clayton2018-04-271-4/+0
| | | | | | | | Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-202-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
* [elf] Remove one copy of the section merging codePavel Labath2018-03-091-32/+4
| | | | | | | | | | | | | | | | Summary: Besides being superfluous, this double merging was actually wrong and causing some sections to be added twice. The reason for that was that the code assumes section IDs are unique in the section list, but this is only true if all sections in the list come from the same object file. Reviewers: fjricci, jankratochvil Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D44157 llvm-svn: 327123
* ObjectFileMachO: split CreateSections mega-function into more manageable chunksPavel Labath2018-03-062-508/+517
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In an effort to understand the function's operation, I've split it into logical pieces. Parsing of a single segment is moved to a separate function (and the parsing state that is carried from one segment to another is explicitly captured in the SegmentParsingContext object). I've also extracted some pieces of code which were already standalone (validation of the segment load command, determining the section type, determining segment permissions) into separate functions. Parsing of a single section within the segment should probably also be a separate function, but I've left that for a separate patch. This patch is intended to be NFC. Reviewers: clayborg, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44074 llvm-svn: 326791
* ObjectFileMachO: use early return to remove one nesting level from ↵Pavel Labath2018-03-031-532/+513
| | | | | | | | CreateSections() NFCI llvm-svn: 326667
* Revert "[lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-02-282-44/+1
| | | | | | | | | | | | regions" This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF -- some parts of the class use physical addresses, and some use virtual. This has manifested itself as us not being able to set the load address of the vdso "module" on android. llvm-svn: 326367
* [lldb] Use vFlash commands when writing to target's flash memory regionsPavel Labath2018-02-272-1/+44
| | | | | | | | | | | | | | | | | | | | | | Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 326261
* lldb running on an ios device is using the _dyld_get_all_image_infos()Jason Molenda2018-02-071-0/+21
| | | | | | | | | SPI call to to find its own shared cache's UUID. On newer sytems we need to use the a new SPI which will return the UUID directly. <rdar://problem/36625871> llvm-svn: 324437
* Fix parsing of object files with "early" section headersPavel Labath2018-02-051-46/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
* Compile the LLDB tests out-of-tree.Adrian Prantl2018-01-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch is the result of a discussion on lldb-dev, see http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for background. For each test (should be eventually: each test configuration) a separate build directory is created and we execute make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test In order to make this work all LLDB tests need to be updated to find the executable in the test build directory, since CWD still points at the test's source directory, which is a requirement for unittest2. Although we have done extensive testing, I'm expecting that this first attempt will break a few bots. Please DO NOT HESITATE TO REVERT this patch in order to get the bots green again. We will likely have to iterate on this some more. Differential Revision: https://reviews.llvm.org/D42281 llvm-svn: 323803
* Add LLDB_LOG_ERROR macroPavel Labath2018-01-301-6/+5
| | | | | | | | | | | | | | | | Summary: The difference between this and regular LLDB_LOG is that this one clears the error object unconditionally. This was inspired by the ObjectFileELF bug (r322664), where the error object was being cleared only if logging was enabled. Reviewers: davide, zturner, jingham, clayborg Subscribers: lldb-commits, emaste Differential Revision: https://reviews.llvm.org/D42182 llvm-svn: 323753
* Fix assertion in ObjectFileELFPavel Labath2018-01-171-0/+2
| | | | | | | | | | In D40616 I (mistakenly) assumed that logging an llvm::Error would clear it. This of course is only true if logging is actually enabled. This fixes the assertion by manually clearing the error, but it raises the point of whether we need a special error-clearing logging primitive. llvm-svn: 322664
* Make sure DataBufferLLVM contents are writablePavel Labath2017-12-213-45/+23
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We sometimes need to write to the object file we've mapped into memory, generally to apply relocations to debug info sections. We've had that ability before, but with the introduction of DataBufferLLVM, we have lost it, as the underlying llvm class (MemoryBuffer) only supports read-only mappings. This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer class as a back-end, as this one guarantees to return a writable buffer. This removes the need for the "Private" flag to the DataBufferLLVM creation functions, as it was really used to mean "writable". The LLVM function also does not have the NullTerminate flag, so I've modified our clients to not require this feature and removed that flag as well. Reviewers: zturner, clayborg, jingham Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D40079 llvm-svn: 321255
* Add LLVMObject dependency to our ObjectFileELF pluginPavel Labath2017-12-181-0/+1
| | | | llvm-svn: 320967
* Fix 32-bit builds broken by 320813Pavel Labath2017-12-151-2/+2
| | | | | | cast to size_t to avoid narrowing error. llvm-svn: 320816
* ObjectFileELF: Add support for compressed sectionsPavel Labath2017-12-152-0/+62
| | | | | | | | | | | | | | | | Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are sometimes compressed, particuarly in the split-dwarf case. This functionality is only available if llvm is compiled with zlib support. Reviewers: clayborg, zturner Subscribers: emaste, mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D40616 llvm-svn: 320813
* Add a symbols subcommand to lldb-test.Zachary Turner2017-12-021-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D40745 llvm-svn: 319599
* Fix alignment of arm64 fpu register context structureJason Molenda2017-11-161-1/+1
| | | | | | | | | | so it has the same padding as the kernel's definition which is written in terms of uint128_t. Original patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318357
OpenPOWER on IntegriCloud