summaryrefslogtreecommitdiffstats
path: root/lldb/lit/Modules
Commit message (Collapse)AuthorAgeFilesLines
* [test] Rename `Modules` to `ObjectFile` (NFC)Jonas Devlieghere2019-10-0762-3154/+0
| | | | llvm-svn: 373955
* [lldb][ELF] Read symbols from .gnu_debugdata sect.Konrad Kleine2019-10-075-0/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the .symtab section is stripped from the binary it might be that there's a .gnu_debugdata section which contains a smaller .symtab in order to provide enough information to create a backtrace with function names or to set and hit a breakpoint on a function name. This change looks for a .gnu_debugdata section in the ELF object file. The .gnu_debugdata section contains a xz-compressed ELF file with a .symtab section inside. Symbols from that compressed .symtab section are merged with the main object file's .dynsym symbols (if any). In addition we always load the .dynsym even if there's a .symtab section. For example, the Fedora and RHEL operating systems strip their binaries but keep a .gnu_debugdata section. While gdb already can read this section, LLDB until this patch couldn't. To test this patch on a Fedora or RHEL operating system, try to set a breakpoint on the "help" symbol in the "zip" binary. Before this patch, only GDB can set this breakpoint; now LLDB also can do so without installing extra debug symbols: lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h The above line runs LLDB in batch mode and on the "/usr/bin/zip -h" target: (lldb) target create "/usr/bin/zip" Current executable set to '/usr/bin/zip' (x86_64). (lldb) settings set -- target.run-args "-h" Before the program starts, we set a breakpoint on the "help" symbol: (lldb) b help Breakpoint 1: where = zip`help, address = 0x00000000004093b0 Once the program is run and has hit the breakpoint we ask for a backtrace: (lldb) r Process 10073 stopped * thread #1, name = 'zip', stop reason = breakpoint 1.1 frame #0: 0x00000000004093b0 zip`help zip`help: -> 0x4093b0 <+0>: pushq %r12 0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056 0x4093b9 <+9>: movl $0x1, %edi 0x4093be <+14>: xorl %eax, %eax Process 10073 launched: '/usr/bin/zip' (x86_64) (lldb) bt * thread #1, name = 'zip', stop reason = breakpoint 1.1 * frame #0: 0x00000000004093b0 zip`help frame #1: 0x0000000000403970 zip`main + 3248 frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243 frame #3: 0x0000000000408cee zip`_start + 46 In order to support the .gnu_debugdata section, one has to have LZMA development headers installed. The CMake section, that controls this part looks for the LZMA headers and enables .gnu_debugdata support by default if they are found; otherwise or if explicitly requested, the minidebuginfo support is disabled. GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6 (2013). Reviewers: espindola, labath, jankratochvil, alexshap Reviewed By: labath Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D66791 llvm-svn: 373891
* [LLDB] Add tests for PECOFF arm architecture identificationMartin Storsjo2019-09-242-0/+172
| | | | | | | | | | | | | | | Add a test case for the change from SVN r372657, and for the preexisting ARM identification. Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak the ArmNt case to set the architecture to armv7 (ArmNt never ran on anything lower than that). (This avoids a case where ArchSpec::MergeFrom would override the arch from arm to armv7 and ArchSpec::CoreUpdated would reset the OS to unknown at the same time.) Differential Revision: https://reviews.llvm.org/D67951 llvm-svn: 372741
* Revert "[LLDB][ELF] Load both, .symtab and .dynsym sections"Konrad Kleine2019-09-114-100/+0
| | | | | | This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41. llvm-svn: 371625
* Revert "[LLDB][ELF] Fixup for comments in D67390"Konrad Kleine2019-09-112-2/+2
| | | | | | This reverts commit 813f05915d29904878d926f9849ca3dbe78096af. llvm-svn: 371624
* [LLDB][ELF] Fixup for comments in D67390Konrad Kleine2019-09-112-2/+2
| | | | llvm-svn: 371600
* [LLDB][ELF] Load both, .symtab and .dynsym sectionsKonrad Kleine2019-09-114-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change ensures that the .dynsym section will be parsed even when there's already is a .symtab. It is motivated because of minidebuginfo (https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html#MiniDebugInfo). There it says: Keep all the function symbols not already in the dynamic symbol table. That means the .symtab embedded inside the .gnu_debugdata does NOT contain the symbols from .dynsym. But in order to put a breakpoint on all symbols we need to load both. I hope this makes sense. My other patch D66791 implements support for minidebuginfo, that's why I need this change. Reviewers: labath, espindola, alexshap Subscribers: JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67390 llvm-svn: 371599
* Upstream support for macCatalyst Mach-O binaries.Adrian Prantl2019-08-231-2/+12
| | | | | | | | | | | | On macOS one Mach-O slice can contain multiple load commands: One load command for being loaded into a macOS process and one load command for being loaded into a macCatalyst process. This patch adds support for the new load command and makes sure ObjectFileMachO returns the Architecture that matches the Module. Differential Revision: https://reviews.llvm.org/D66626 llvm-svn: 369814
* ObjectFileELF: Convert a unit test to a lit testPavel Labath2019-08-081-0/+93
| | | | | | It is much easier to test this functionality via lldb-test. llvm-svn: 368289
* ObjectFileELF: permit thread-local sections with overlapping file addressesPavel Labath2019-08-062-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In an attempt to make file-address-based lookups more predictable, in D55998 we started ignoring sections which would result in file address overlaps. It turns out this was too aggressive because thread-local sections typically will have file addresses which apear to overlap regular data/code. This does not cause a problem at runtime because thread-local sections are loaded into memory using special logic, but it can cause problems for lldb when trying to lookup objects by their file address. This patch changes ObjectFileELF to permit thread-local sections to overlap regular ones by essentially giving them a separate address space. It also makes them more symmetrical to regular sections by creating container sections from PT_TLS segments. Simultaneously, the patch changes the regular file address lookup logic to ignore sections with the thread-specific bit set. I believe this is what the users looking up file addresses would typically expect, as looking up thread-local data generally requires more complex logic (e.g. DWARF has a special opcode for that). Reviewers: clayborg, jingham, MaskRay Subscribers: emaste, aprantl, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D65282 llvm-svn: 368010
* SymbolVendorELF: Perform build-id lookup even without a debug linkPavel Labath2019-08-062-1/+33
| | | | | | | | | | | | | | | | | | | | | | Summary: The debug link and build-id lookups are two independent ways one can search for a separate symbol file. However, our implementation in SymbolVendorELF was tying the two together and refusing to look up the symbol file based on a build id if the file did not contain a debug link. This patch makes it possible to search for the symbol file with just one of the two methods available. To demonstrate, I split the build-id-case test into two, so that we test the search using both methods. Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap Subscribers: emaste, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65561 llvm-svn: 367994
* ObjectFileELF: Add support for gnu-style compressed sectionsPavel Labath2019-07-101-1/+12
| | | | | | | | | With this style, a compressed section is indicated by a "z" in the section name, instead of a section header flag. This patch consists of two small tweaks: - use an llvm Decompressor method in order to properly detect compressed sections - make sure we recognise .zdebug_info (and friends) when classifying section types. llvm-svn: 365654
* Recognise debug_types.dwo as a debug info sectionPavel Labath2019-06-121-0/+7
| | | | | | This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
* Breakpad: Add support for the arm64e "architecture"Pavel Labath2019-06-102-0/+6
| | | | llvm-svn: 362960
* [PECOFF] Implementation of ObjectFilePECOFF:: GetUUID()Aaron Smith2019-04-302-1/+95
| | | | | | | | | | | | | | | | | | | Summary: Provide an implementation of GetUUID() for remote debugging scenarios. Return a PDB's GUID (or PDB70's Signature) as the UUID. Reviewers: amccarth, labath Reviewed By: labath Subscribers: amccarth, clayborg, Hui, labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56229 llvm-svn: 359528
* Breakpad: Match the new UUID algorithm in minidumpsPavel Labath2019-04-164-2/+76
| | | | | | | | | | | | | | | D59433 and D60501 changed the way UUIDs are computed from minidump files. This was done to synchronize the U(G)UID representation with the native tools of given platforms, but it created a mismatch between minidumps and breakpad files. This updates the breakpad algorithm to match the one found in minidumps, and also adds a couple of tests which should fail if these two ever get out of sync. Incidentally, this means that the module id in the breakpad files is almost identical to our notion of UUIDs, so the computation algorithm can be somewhat simplified. llvm-svn: 358500
* test/PECOFF: Remove REQUIRES: system-windowsPavel Labath2019-04-162-2/+2
| | | | | | | These tests run fine on non-windows platforms too. Instead I add REQUIRES: lld, as that is what they really require. llvm-svn: 358499
* Breakpad: Parse Stack CFI recordsPavel Labath2019-04-091-1/+1
| | | | | | | | | | | | | | | | | Summary: This patch adds support for parsing STACK CFI records from breakpad files. The expressions specifying the values of registers are not parsed.The idea is that these will be handed off to the postfix expression -> dwarf compiler, once it is extracted from the internals of the NativePDB plugin. Reviewers: clayborg, amccarth, markmentovai Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D60268 llvm-svn: 357975
* Breakpad: Refine record classification codePavel Labath2019-04-043-2/+11
| | | | | | | | | | | | | | | | | Previously we would classify all STACK records into a single bucket. This is not really helpful, because there are three distinct types of records beginning with the token "STACK" (STACK CFI INIT, STACK CFI, STACK WIN). To be consistent with how we're treating other records, we should classify these as three different record types. It also implements the logic to put "STACK CFI INIT" and "STACK CFI" records into the same "section" of the breakpad file, as they are meant to be read together (similar to how FUNC and LINE records are treated). The code which performs actual parsing of these records will come in a separate patch. llvm-svn: 357691
* [LLDB] - Update the test cases after yaml2obj change.George Rimar2019-04-032-12/+10
| | | | | | | | | https://reviews.llvm.org/D60122 (r357595) changed the symbols description format in yaml2obj. This change updates the LLDB tests. llvm-svn: 357600
* [lldb] [ObjectFile/ELF] Fix recognizing NetBSD imagesMichal Gorny2019-02-204-1/+35
| | | | | | | | | | | | | | | | | | | | | Split the recognition into NetBSD executables & shared libraries and core(5) files. Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged in the same way as regular NetBSD executables. Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG, IDENT_DECSZ, IDENT_NAMESZ and PROCINFO. The new values detect correctly the NetBSD images. The patch has been originally written by Kamil Rytarowski. I've added tests and applied minor code changes per review. The work has been sponsored by the NetBSD Foundation. Differential Revision: https://reviews.llvm.org/D42870 llvm-svn: 354466
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-181-0/+86
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* ObjectFilePECOFF: Create a "container" section spanning the entire module imagePavel Labath2019-02-132-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is coming from the discussion in D55356 (the most interesting part happened on the mailing list, so it isn't reflected on the review page). In short the issue is that lldb assumes that all bytes of a module image in memory will be backed by a "section". This isn't the case for PECOFF files because the initial bytes of the module image will contain the file header, which does not correspond to any normal section in the file. In particular, this means it is not possible to implement GetBaseAddress function for PECOFF files, because that's supposed point to the first byte of that header. If my (limited) understanding of how PECOFF files work is correct, then the OS is expecded to load the entire module into one continuous chunk of memory. The address of that chunk (+/- ASLR) is given by the "image base" field in the COFF header, and it's size by "image size". All of the COFF sections are then loaded into this range. If that's true, then we can model this behavior in lldb by creating a "container" section to represent the entire module image, and then place other sections inside that. This would make be consistent with how MachO and ELF files are modelled (except that those can have multiple top-level containers as they can be loaded into multiple discontinuous chunks of memory). This change required a small number of fixups in the PDB plugins, which assumed a certain order of sections within the object file (which obivously changes now). I fix this by changing the lookup code to use section IDs (which are unchanged) instead of indexes. This has the nice benefit of removing spurious -1s in the plugins as the section IDs in the pdbs match the 1-based section IDs in the COFF plugin. Besides making the implementation of GetBaseAddress possible, this also improves the lookup of addresses in the gaps between the object file sections, which will now be correctly resolved as belonging to the object file. Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo Reviewed By: clayborg, lemo Subscribers: JDevlieghere, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56537 llvm-svn: 353916
* ELF: Fix base address computation code for files generated by yaml2objPavel Labath2019-01-111-0/+34
| | | | | | | | | | | | | | | | | | | | | The code was assuming that the elf file will have a PT_LOAD segment starting from the first byte of the file. While this is true for files generated by most linkers (it's a way of saving space), it is not a requirement. And files not satisfying this constraint can still be perfectly executable. yaml2obj is one of the tools which produces files like this. This patch relaxes the check in ObjectFileELF to take the address of the first PT_LOAD segment as the base address of the object (instead of the one with the offset 0). Since the PT_LOAD segments are supposed to be sorted according to the VM address, this entry will also be the one with the lowest VM address. If we ever run into files which don't have the PT_LOAD segments sorted, we can easily change this code to return the lowest VM address as the base address (if that is the correct thing to do for these files). llvm-svn: 350923
* PECOFF: Fix section name computationPavel Labath2019-01-101-0/+52
| | | | | | | | | | | | | | | | | | If a section name is exactly 8 bytes long (or has been truncated to 8 bytes), it will not contain the terminating nul character. This means reading the name as a c string will pick up random data following the name field (which happens to be the section vm size). This fixes the name computation to avoid out-of-bounds access and adds a test. Reviewers: zturner, stella.stamenova Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D56124 llvm-svn: 350809
* Implement ObjectFileELF::GetBaseAddressPavel Labath2019-01-102-2/+31
| | | | | | | | | Summary: The concept of a base address was already present in the implementation (it's needed for computing section load addresses properly), but it was never exposed through this function. This fixes that. llvm-svn: 350804
* ELF: create "container" sections from PT_LOAD segmentsPavel Labath2019-01-099-2/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the result of the discussion in D55356, where it was suggested as a solution to representing the addresses that logically belong to a module in memory, but are not a part of any of its sections. The ELF PT_LOAD segments are similar to the MachO "load commands", except that the relationship between them and the object file sections is a bit weaker. While in the MachO case, the sections belonging to a specific segment are placed directly inside it in the object file logical structur, in the ELF case, the sections and segments form two separate hierarchies. This means that it is in theory possible to create an elf file where only a part of a section would belong to some segment (and another part to a different one). However, I am not aware of any tool which would produce such a file (and most tools will have problems ingesting them), so this means it is still possible to follow the MachO model and make sections children of the PT_LOAD segments. In case we run into (corrupt?) files with overlapping sections, I have added code (and tests) which adjusts the sizes and/or drops the offending sections in order to present a reasonable image to the upper layers of LLDB. This is mostly done for completeness, as I don't anticipate running into this situation in the real world. However, if we do run into it, and the current behavior is not suitable for some reason, we can implement this logic differently. Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D55998 llvm-svn: 350742
* ObjectFileBreakpad: Implement sectionsPavel Labath2019-01-076-0/+156
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch allows ObjectFileBreakpad to parse the contents of Breakpad files into sections. This sounds slightly odd at first, but in essence its not too different from how other object files handle things. For example in elf files, the symtab section consists of a number of "records", where each record represents a single symbol. The same is true for breakpad's PUBLIC section, except in this case, the records will be textual instead of binary. To keep sections contiguous, I create a new section every time record type changes. Normally, the breakpad processor will group all records of the same type in one block, but the format allows them to be intermixed, so in general, the "object file" may contain multiple sections with the same record type. Reviewers: clayborg, zturner, lemo, markmentovai, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55434 llvm-svn: 350511
* ELF: Don't create sections for section header index 0Pavel Labath2018-12-182-1/+6
| | | | | | | | | | | | | | | | | | | Summary: The first section header does not define a real section. Instead it is used for various elf extensions. This patch skips creation of a section for index 0. This has one furtunate side-effect, in that it allows us to use the section header index as the Section ID (where 0 is also invalid). This way, we can get rid of a lot of spurious +1s in the ObjectFileELF code. Reviewers: clayborg, krytarowski, joerg, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D55757 llvm-svn: 349498
* lldb-test: Improve newline handlingPavel Labath2018-12-151-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously lldb-test's LinePrinter would output the indentation spaces even on completely empty lines. This is not nice, as trailing spaces get flagged as errors in some tools/editors, and it prevents FileCheck's CHECK-EMPTY from working. Equally annoying was the fact that the LinePrinter did not terminate it's output with a newline (instead it would leave the unterminated hanging indent from the last NewLine() command), which meant that the shell prompt following the lldb-test command came out wrong. This fixes both issues by changing how newlines are handled. NewLine(), which was ending the previous line ('\n') *and* begging the next line by printing the indent, is now "demoted" to just printing literal "\n". Instead, lines are now delimited via a helper Line object, which makes sure the line is indented and terminated in an RAII fashion. The typical usage would be: Printer.line() << "This text will be indented and terminated"; If one needs to do more work than it will fit into a single statement, one can also assign the result of the line() function to a local variable. The line will then be terminated when that object goes out of scope. Reviewers: zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55597 llvm-svn: 349269
* ELF: more section creation cleanupPavel Labath2018-12-156-6/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch attempts to move as much code as possible out of the CreateSections function to make room for future improvements there. Some of this may be slightly over-engineered (VMAddressProvider), but I wanted to keep the logic of this function very simple, because once I start taking segment headers into acount (as discussed in D55356), the function is going to grow significantly. While in there, I also added tests for various bits of functionality. This should be NFC, except that I changed the order of hac^H^Heuristicks for determining section type slightly. Previously, name-based deduction (.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB -> symtab) one. In fact we would assert if we ran into a .text section with type SHT_SYMTAB. Though unlikely to matter in practice, this order seemed wrong to me, so I have inverted it. Reviewers: clayborg, krytarowski, espindola Subscribers: emaste, arichardson, lldb-commits Differential Revision: https://reviews.llvm.org/D55706 llvm-svn: 349268
* Classify tests in lit/ModulesPavel Labath2018-12-139-0/+0
| | | | | | | | We've recently developed a convention where the tests are placed into subfolders according to the object file type. This applies that convention to existing tests too. llvm-svn: 349027
* ELF: Clean up section type computationPavel Labath2018-12-124-16/+40
| | | | | | | | | | | | | Move code into a separate function, and replace the if-else chain with llvm::StringSwitch. A slight behavioral change is that now I use the section flags (SHF_TLS) instead of the section name to set the thread-specific property. There is no explanation in the original commit introducing this (r153537) as to why that was done this way, but the new behavior should be more correct. llvm-svn: 348936
* lldb-test: Add ability to dump subsectionsPavel Labath2018-12-121-0/+106
| | | | | | | | Previously, lldb-test would only print top-level sections. However, in lldb, sections can contain other sections. This teaches lldb-test to print nested sections too. llvm-svn: 348924
* Re-commit "Introduce ObjectFileBreakpad"Pavel Labath2018-12-108-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r348592, which was reverted due to a failing test on macos. The issue was that I was passing a null pointer for the "CreateMemoryInstance" callback when registering ObjectFileBreakpad, which caused crashes when attemping to load modules from memory. The correct thing to do is to pass a callback which always returns a null pointer (as breakpad files are never loaded in inferior memory). It turns out that there is only one test which exercises this code path, and it's mac-only, so I've create a new test which should run everywhere (except windows, as one cannot delete an executable which is being run). Unfortunately, this test still fails on linux for other reasons, but at least it gives us something to aim for. The original commit message was: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348773
* Revert "Introduce ObjectFileBreakpad"Shafik Yaghmour2018-12-078-55/+0
| | | | | | | | This reverts commit 5e056e624cc57bb22a4c29a70b522783c6242293. Reverting because this lldb cmake bot: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/ llvm-svn: 348629
* Introduce ObjectFileBreakpadPavel Labath2018-12-078-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348592
* [pecoff] Implement ObjectFilePECOFF::GetDependedModules()Aaron Smith2018-12-063-0/+343
| | | | | | | | | | | | | | | | | | Summary: This parses entries in pecoff import tables for imported DLLs and is intended as the first step to allow LLDB to load a PE's shared modules when creating a target on the LLDB console. Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith Reviewed By: labath, asmith Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor Differential Revision: https://reviews.llvm.org/D53094 llvm-svn: 348527
* Remove REQUIRES: darwin from a couple of MachO testsPavel Labath2018-12-062-2/+0
| | | | | | lldb is able to parse MachO files also on other platforms nowadays. llvm-svn: 348476
* Fix a bug in the parsing of the LC_BUILD_VERSION Mach-O load command.Adrian Prantl2018-11-132-1/+208
| | | | | | | | | LC_BUILD_VERSION records are of variable length. The original code would use uninitialized memory when the size of a record was exactly 24. rdar://problem/46032185 llvm-svn: 346812
* Upstreaming the BridgeOS device support and the Jason Molenda2018-10-111-0/+210
| | | | | | | | | | | | | | | 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
* Misc module/dwarf logging improvementsLeonard Mosescu2018-08-071-2/+1
| | | | | | | | | | | | | | 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
* ELF: Replace the header-extension unit test with a lit onePavel Labath2018-07-192-1/+73
| | | | | | | | | The new test checks that we are actually able to read data from these kinds of elf headers correctly instead of just that we read the section number correctly. It is also easier to figure out what's going on in the test. llvm-svn: 337459
* Add a test for reading lld-generated build-idsPavel Labath2018-06-296-6/+32
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This test makes sure we are able to read the shorter build-ids which are generated by lld. To make this work, I've extended lldb-test to print the UUID of the loaded object file. I've renamed the lldb-test subcommand from "module-sections" to "object-file" to reflect the fact it prints more than just the sections. I've also added the module Architecture to the output, so we could avoid printing the entire symbol file information just to get the ArchSpec details in the lc_version_min test (which was also the only test in it's folder not using the module-sections command). Reviewers: aprantl, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48646 llvm-svn: 335967
* Add .debug_names section glue codePavel Labath2018-06-011-0/+9
| | | | llvm-svn: 333743
* Make ObjectFileMachO work on non-darwin platformsPavel Labath2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch we were unable to write cross-platform MachO tests because the parsing code did not compile on other platforms. The reason for that was that ObjectFileMachO depended on RegisterContextDarwin_arm(64)? (presumably for core file parsing) and the two Register Context classes uses constants from the system headers (KERN_SUCCESS, KERN_INVALID_ARGUMENT). As far as I can tell, these two files don't actually interact with the darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel process plugin (even though it has "kernel" in the name, this one communicates with it via network packets and not syscalls). For the time being I have created OS-independent definitions of these constants and made the register context classes use those. Long term, the error handling in these classes should be probably changed to use more standard mechanisms such as Status or Error classes. This is the only change necessary (apart from build system glue) to make ObjectFileMachO work on other platforms. To demonstrate that, I remove REQUIRES:darwin from our (only) cross-platform mach-o test. Reviewers: jasonmolenda, aprantl, clayborg, javed.absar Subscribers: mgorny, lldb-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D46934 llvm-svn: 332702
* Retrieve the deployment target when retrieving an object file's triple.Adrian Prantl2018-05-111-0/+205
| | | | | | | | | | | | 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-081-2/+16
| | | | | | | | 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
* ObjectFileELF: Add support for arbitrarily named code sectionsPavel Labath2018-04-301-0/+14
| | | | | | | | | | | | | | | | | | | 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-293-0/+28
| | | | | | Differential revision: https://reviews.llvm.org/D40468 llvm-svn: 331148
OpenPOWER on IntegriCloud