summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/DWARF] Move location list sections into DWARFContextPavel Labath2020-01-141-2/+4
| | | | | | These are the last sections not managed by the DWARFContext object. I also introduce separate SectionType enums for dwo section variants, as this is necessary for proper handling of single-file split dwarf.
* [lldb] Fix lookup of symbols with the same address range but different bindingJan Kratochvil2020-01-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30): PASS: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325 frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243 frame #7: 0x000000000040106e a.out`_start + 46 vs. FAIL - unrecognized abort() function: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325 frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243 frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46 The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28). It is due to: Symbol table '.dynsym' contains 2361 entries: Valu e Size Type Bind Vis Name 0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely 000000000002276e 548 FUNC GLOBAL DEFAULT abort 000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5 000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort 0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely GDB has some more complicated preferences between overlapping and/or sharing address symbols, I have made here so far the most simple fix for this case. Differential revision: https://reviews.llvm.org/D63540
* [lldb] Add boilerplate to recognize the .debug_rnglists.dwo sectionPavel Labath2019-11-261-0/+1
|
* Remove obsolete parameter.Adrian Prantl2019-10-091-1/+0
| | | | llvm-svn: 374185
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-091-7/+1
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* Unify the two CRC implementationsHans Wennborg2019-10-091-5/+3
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-081-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* [lldb][ELF] Read symbols from .gnu_debugdata sect.Konrad Kleine2019-10-071-8/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Explicitly set entry point arch when it's thumb"Antonio Afonso2019-10-041-40/+0
| | | | | | | | Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate. This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be. llvm-svn: 373687
* Explicitly set entry point arch when it's thumbAntonio Afonso2019-10-041-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68069 llvm-svn: 373680
* Revert "[LLDB][ELF] Load both, .symtab and .dynsym sections"Konrad Kleine2019-09-111-18/+8
| | | | | | This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41. llvm-svn: 371625
* Revert "[LLDB][ELF] Fixup for comments in D67390"Konrad Kleine2019-09-111-5/+6
| | | | | | This reverts commit 813f05915d29904878d926f9849ca3dbe78096af. llvm-svn: 371624
* [LLDB][ELF] Fixup for comments in D67390Konrad Kleine2019-09-111-6/+5
| | | | llvm-svn: 371600
* [LLDB][ELF] Load both, .symtab and .dynsym sectionsKonrad Kleine2019-09-111-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* ObjectFileELF: Remove NT_*** constantsPavel Labath2019-08-071-36/+1
| | | | | | | llvm now has definitions of those in BinaryFormat/ELF.h. Use those instead. llvm-svn: 368159
* ObjectFileELF: permit thread-local sections with overlapping file addressesPavel Labath2019-08-061-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ObjectFile[ELF]: Refactor gnu_debuglink interfacePavel Labath2019-08-051-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The contents of the gnu_debuglink section were passed through the GetDebugSymbolFilePaths interface, which was more generic than needed. As the only class implementing this function is ObjectFileELF, we can modify the function to return just a single FileSpec (instead of a list). Also, since the SymbolVendorELF already assumes ELF object files, we don't have to make this method available on the generic ObjectFile interface -- instead we can put it on ObjectFileELF directly. This change also makes is so that if the Module has an explicit symbol file spec set, we disregard the value the value of the debug link (instead of doing a secondary lookup using that). I think it makes sense to honor the users wishes if he had explicitly set the symbol file spec, and this seems to be consistent with what SymbolVendorMacOSX is doing (SymbolVendorMacOSX.cpp:125). The main reason for making these changes is to make the treatment of build-ids and debug links simpler in the follow-up patch. Reviewers: clayborg, jankratochvil, mgorny, espindola Subscribers: emaste, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65560 llvm-svn: 367824
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
* ObjectFileELF: Use llvm::JamCRC to refactor CRC32 computationFangrui Song2019-07-261-67/+9
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D65318 llvm-svn: 367090
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-51/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* ELF: Fix a "memset clearing object of non-trivial type" warningPavel Labath2019-07-221-13/+2
| | | | | | | | Just delete the memset as the ELFHeader constructor already zero-initializes the object. Also clean up the ObjectFileELF constructors/desctructors while I'm in there. llvm-svn: 366692
* ObjectFileELF: Add support for gnu-style compressed sectionsPavel Labath2019-07-101-28/+31
| | | | | | | | | 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/+1
| | | | | | This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Simplify ArchSpec::IsMIPS()Fangrui Song2019-05-161-5/+1
| | | | llvm-svn: 360865
* [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptorsStefan Granitz2019-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First part of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's is still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 The address of the breakpoint site is corrupt: the 0x4 value we end up with, looks like an offset on a zero base address. When we parse the ELF section headers from the JIT descriptor, the load address for the text section we find in `header.sh_addr` is correct. The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` (follow it from `ObjectFileELF::CreateSections()`). Here we think the object type was `eTypeObjectFile` and unleash some extra logic [1] which essentially overwrites the address with a zero value. The object type is deduced from the ELF header's `e_type` in `ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF header has no representation for it [2]. Instead the in-memory ELF object states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from `lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT side instead? In fact, relocations were already applied at this point, so "Relocatable" is not quite exact.) So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call `GetType()`, which returns the explicit value or otherwise falls back to `CalculateType()`. LLDB then sets the breakpoint successfully. Next step: debug info. ``` Process 1056 stopped * thread #1, name = 'lli', stop reason = breakpoint 1.2 frame #0: 0x00007ffff7ff7000 JIT(0x3ba2030)`jitbp() JIT(0x3ba2030)`jitbp: -> 0x7ffff7ff7000 <+0>: pushq %rbp 0x7ffff7ff7001 <+1>: movq %rsp, %rbp 0x7ffff7ff7004 <+4>: movabsq $0x7ffff7ff6000, %rdi ; imm = 0x7FFFF7FF6000 0x7ffff7ff700e <+14>: movabsq $0x7ffff6697e80, %rcx ; imm = 0x7FFFF6697E80 ``` [1] It was first introduced with https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the original breaking change. The code has changed a lot since then. [2] ELF object types: https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110 Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, stella.stamenova Reviewed By: labath, clayborg Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, yurydelendik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61611 llvm-svn: 360354
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-41/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* [Platform] Remove Kalimba PlatformJonas Devlieghere2019-03-271-71/+2
| | | | | | | | | This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-111-2/+2
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-2/+2
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Move RangeMap.h into UtilityPavel Labath2019-03-061-1/+1
| | | | | | | | | | | | | | Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
* [Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpecAlex Langford2019-02-261-1/+1
| | | | | | | | | | | | | | Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
* [lldb] [ObjectFile/ELF] Fix recognizing NetBSD imagesMichal Gorny2019-02-201-12/+29
| | | | | | | | | | | | | | | | | | | | | 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
* Move UnwindTable from ObjectFile to ModulePavel Labath2019-02-141-2/+2
| | | | | | | | | | | | | | | Summary: This is a preparatory step to enable adding extra unwind strategies by symbol file plugins. This has been discussed on the lldb-dev mailing list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. Reviewers: jasonmolenda, clayborg, espindola Subscribers: lemo, emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D58129 llvm-svn: 354033
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-37/+37
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-121-2/+2
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* Simplify ObjectFile::GetUUIDPavel Labath2019-02-111-33/+27
| | | | | | | | | instead of returning the UUID through by-ref argument and a boolean value indicating success, we can just return it directly. Since the UUID class already has an invalid state, it can be used to denote the failure without the additional bool. llvm-svn: 353714
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* ELF: Fix base address computation code for files generated by yaml2objPavel Labath2019-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Implement ObjectFileELF::GetBaseAddressPavel Labath2019-01-101-10/+15
| | | | | | | | | 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-091-56/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-14/+9
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* ELF: Don't create sections for section header index 0Pavel Labath2018-12-181-21/+15
| | | | | | | | | | | | | | | | | | | 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
* ELF: more section creation cleanupPavel Labath2018-12-151-67/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-5/+5
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* ELF: Clean up section type computationPavel Labath2018-12-121-144/+41
| | | | | | | | | | | | | 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
* ELF: Simplify program header iterationPavel Labath2018-12-121-63/+35
| | | | | | | | | | | | | Instead of GetProgramHeaderCount+GetProgramHeaderByIndex, expose an ArrayRef of all program headers, to enable range-based iteration. Instead of GetSegmentDataByIndex, expose GetSegmentData, taking a program header (reference). This makes the code simpler by enabling range-based loops and also allowed to remove some null checks, as it became locally obvious that some pointers can never be null. llvm-svn: 348928
* [LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".George Rimar2018-11-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Test cases were updated to not use the local compilation dir which is different between development pc and build bots. Original commit message: [LLDB] - Support the single file split DWARF. DWARF5 spec describes a single file split dwarf case (when .dwo sections are in the .o files). Problem is that LLDB does not work correctly in that case. The issue is that, for example, both .debug_info and .debug_info.dwo has the same type: eSectionTypeDWARFDebugInfo. And when code searches section by type it might find the regular debug section and not the .dwo one. The patch fixes that. With it, LLDB is able to work with output compiled with -gsplit-dwarf=single flag correctly. Differential revision: https://reviews.llvm.org/D52403 llvm-svn: 346855
OpenPOWER on IntegriCloud