summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [Symbol] Remove commented out code from CompileUnitAlex Langford2019-08-071-43/+0
| | | | llvm-svn: 368205
* Add support for deterministically linked binaries on macOS to lldb.Nico Weber2019-08-072-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When ld64 links a binary deterministically using the flag ZERO_AR_DATE, it sets a timestamp of 0 for N_OSO members in the symtab section, rather than the usual last modified date of the object file. Prior to this patch, lldb would compare the timestamp from the N_OSO member against the last modified date of the object file, and skip loading the object file if there was a mismatch. This patch updates the logic to ignore the timestamp check if the N_OSO member has timestamp 0. The original logic was added in https://reviews.llvm.org/rL181631 as a safety check to avoid problems when debugging if the object file was out of date. This was prior to the introduction of deterministic build in ld64. lld still doesn't support deterministic build. Other code in llvm already relies on and uses the assumption that a timestamp of 0 means deterministic build. For example, commit 9ccfddc39d4d27f9b16fcc72ab30d483151d6d08 adds similar timestamp checking logic to dsymutil, but special cases timestamp 0. Likewise, commit 0d1bb79a0413f221432a7b1d0d2d10c84c4bbb99 adds a long comment describing deterministic archive, which mostly uses timestamp 0 for determinism. Patch from Erik Chen <erikchen@chromium.org>! Differential Revision: https://reviews.llvm.org/D65826 llvm-svn: 368199
* [Driver] Expand the executable path in the target create outputJonas Devlieghere2019-08-072-1/+9
| | | | | | | | | | | | | | | | | | Resolve the path in the target create output. This is nice when passing relative paths to the lldb command line driver. $ lldb ./binary (lldb) target create "./binary" Current executable set to '/absolute/path/to/binary' (x86_64). This change only affects the target create output and does not change the debugger's behavior. It doesn't resolve symbolic links so it won't cause confusing when debugging something like clang++ that's symlinked to clang. Differential revision: https://reviews.llvm.org/D65611 llvm-svn: 368182
* [ExecutionContext] Return the target/process byte order.Jonas Devlieghere2019-08-073-4/+126
| | | | | | | | | | | | | Currently ExecutionContext::GetByteOrder() always returns the host byte order. This seems like a simple mistake: the return keyword appears to have been omitted by accident. This patch fixes that and adds a unit test. Bugreport: https://llvm.org/PR37950 Differential revision: https://reviews.llvm.org/D48704 llvm-svn: 368181
* ProcessElfCore: Remove linux and freebsd NT_*** constantsPavel Labath2019-08-072-46/+21
| | | | | | | These are already defined in llvm/BinaryFormat/ELF.h. Leaving the NetBSD and OpenBSD constants as-is, as they have no llvm counterparts. llvm-svn: 368168
* 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
* A more robust way of testing debug_line parser near the end of modulePavel Labath2019-08-072-3/+28
| | | | | | | | | | | | | | | | | | Summary: While removing -z separate-code makes lld produce place the code at the end of a segment right now, it's possible that future changes to the linker will change that, thereby removing the coverage for the changes in r367983. This patch adds a linker script to one of the line table tests, which ensures that the code (and its line table) will be placed at the very end of a module. Reviewers: MaskRay Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65789 llvm-svn: 368154
* [lldb][CMake] Workaround debugserver code-signing issue in generated Xcode ↵Stefan Granitz2019-08-071-0/+28
| | | | | | | | | | | | | | | | | | | | | project Summary: Explicitly code-sign the LLDB.framework copy of debugserver in the build-tree. This is necessary, because the Xcode-specific logic in `llvm_codesign` [1] has the side-effect that Xcode code-signs after post-build steps (here: after copying debugserver over into the framework). The special case for Xcode was necessary to avoid double-signing errors in the past (see D55116 and D55816). [1] https://github.com/llvm/llvm-project/blob/36fb93982f0e/llvm/cmake/modules/AddLLVM.cmake#L1676 Reviewers: jingham, davide, JDevlieghere, teemperor Reviewed By: JDevlieghere Subscribers: beanz, mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65566 llvm-svn: 368151
* [lldb][NFC] Remove commented out code in ↵Raphael Isemann2019-08-071-18/+0
| | | | | | ClangASTContext::AddMethodToCXXRecordType llvm-svn: 368150
* [lldb][CMake] Fix one more detail in r368066Stefan Granitz2019-08-071-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368148
* [lldb][NFC] Fix typo in 368066Stefan Granitz2019-08-071-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368143
* Detect HAVE_SYS_TYPES_H in lldbHaibo Huang2019-08-078-2/+16
| | | | | | | | | | | | | | | | Summary: After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in Platform.h, or anywhere else in lldb. This change fixes that. Reviewers: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65822 llvm-svn: 368125
* Upstream a few small Apple changes to debugserver - arm64_32, CatalystJason Molenda2019-08-0710-30/+171
| | | | | | | | | Adrian's changes to support Catalyst processes and my changes to support debugserver running on an arm64_32 device (Apple Watch Series 4, which uses an IPL32 model on arm64 cpus). llvm-svn: 368118
* [Gardening] Remove more dead code from IOHandlerJonas Devlieghere2019-08-071-29/+6
| | | | | | Remove more dead code and reformat the file. llvm-svn: 368116
* [lldb][NFC] Minor refactorings to (Clang)ExpressionSourceCodeRaphael Isemann2019-08-062-11/+18
| | | | llvm-svn: 368082
* [SymbolFile] Remove commented out methodAlex Langford2019-08-062-204/+0
| | | | llvm-svn: 368075
* Various build fixes for lldb on MinGWHaibo Huang2019-08-066-0/+22
| | | | | | | | | | Subscribers: mstorsjo, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65691 llvm-svn: 368069
* [lldb][CMake] Generating Xcode projectsStefan Granitz2019-08-063-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Print a warning if the wrong cache script is used when generating a Xcode project, because it's too easy to confuse with Apple-lldb-macOS.cmake ``` When building with Xcode, we recommend using the corresponding cache script. If this was a mistake, clean your build directory and re-run CMake with: -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-Xcode.cmake See: https://lldb.llvm.org/resources/build.html#cmakegeneratedxcodeproject ``` Also set the generator inside the cache script. Reviewers: JDevlieghere, jingham, clayborg Reviewed By: JDevlieghere Subscribers: mgorny, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D65797 llvm-svn: 368066
* Update LLDB to follow changes in llvm::DWARFDebugNames::NameIndex (4/5)Igor Kudrin2019-08-061-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D65640 llvm-svn: 368033
* ObjectFileELF: permit thread-local sections with overlapping file addressesPavel Labath2019-08-064-17/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SymbolVendor: Remove passthrough methodsPavel Labath2019-08-0615-409/+90
| | | | | | | | | | After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo(). llvm-svn: 368001
* SymbolVendorELF: Perform build-id lookup even without a debug linkPavel Labath2019-08-064-85/+121
| | | | | | | | | | | | | | | | | | | | | | 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
* [lldb][NFC] Remove unnecessary cast in ClangUserExpressionRaphael Isemann2019-08-061-5/+3
| | | | llvm-svn: 367989
* Fix line table resolution near the end of a sectionPavel Labath2019-08-066-32/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lld r367537 changed the way the linker organizes sections and segments. This exposed an lldb bug and caused some tests to fail. In all of the failing tests the root cause was the same -- when we were trying to resolve the last address in the line_table section, we failed because it pointed past the end of the section. This patch changes the line table address resolution code to back up the address by one for end-of-sequence entries. This ensures the address still points inside a section/module even if the line table sequence ends at the very end of a section. It also reverts the linker flags which were added to the failing tests to restore previous behavior. Reviewers: clayborg, jingham Subscribers: mgorny, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65647 llvm-svn: 367983
* [Gardening] Remove dead code from ASTDumper (NFC)Jonas Devlieghere2019-08-061-4/+0
| | | | | | These functions are not referenced. llvm-svn: 367978
* [Gardening] Remove dead code from ScriptInterpreterPython (NFC)Jonas Devlieghere2019-08-062-24/+3
| | | | | | The terminal state is never saved or restored. llvm-svn: 367977
* [Gardening] Remove dead code from IOHandler (NFC)Jonas Devlieghere2019-08-061-17/+0
| | | | | | These functions are not referenced. llvm-svn: 367976
* Remove unused function 'SetMangledCounterparts' (NFC)Jonas Devlieghere2019-08-061-17/+0
| | | | | | This function is not referenced. llvm-svn: 367975
* Revert "[CompilerType] Simplify the interface a bit more.."Davide Italiano2019-08-065-8/+38
| | | | | | | | There's actually a test downstream that fails with this. I think we can still get rid of it, but I need to do some work there first. llvm-svn: 367963
* [CompilerType] Simplify the interface a bit more..Davide Italiano2019-08-065-38/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: .. removing IsMeaninglessWithoutTypeResolution(). I'm fairly confident this was introduced to support swift, where static types [without dynamic counterpart] don't carry a lot of value. Since then, the formatters and dynamic type resolution has been rewritten, and we employ different solutions. This function is unused here too, so let's get read of it. <rdar://problem/36377967> Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65782 llvm-svn: 367957
* [CMake] Remove check for the readline target.Jonas Devlieghere2019-08-051-4/+1
| | | | | | | | | | | | This was introduced when we were building a custom readline Python module on Linux [1]. Now that the readline target doesn't exist anymore, it's safe to remove this dependency. This fixes https://llvm.org/PR25136 [1] https://reviews.llvm.org/D13268 llvm-svn: 367956
* [CompilerType] Remove an unused function.Davide Italiano2019-08-055-59/+0
| | | | | | | | | | | | | | | | | | Summary: This simplifies the interface, as I'm trying to understand how we can upstream swift support. <rdar://problem/36377967> Reviewers: teemperor, JDevlieghere, xiaobai, compnerd, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65781 llvm-svn: 367946
* [lldb][NFC] Document and refactor ↵Raphael Isemann2019-08-051-4/+16
| | | | | | ClangPersistentVariables::RemovePersistentVariable llvm-svn: 367936
* [lldb][NFC] Refactor ClangUserExpression::UpdateLanguageForExprRaphael Isemann2019-08-052-16/+21
| | | | | | | | | The UpdateLanguageForExpr should only update the language, but over time it started to do also do different things related to the generation of the expression source code. This patch refactors all the source code generation part into its own function. llvm-svn: 367922
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-052-4/+4
| | | | | | assembly format for better readability llvm-svn: 367867
* [lldb][clang] Reflect LangStandard.h move to clang/BasicRainer Orth2019-08-051-19/+20
| | | | | | | | | | | D65562 <https://reviews.llvm.org/D65562> moves LangStandard.h from clang/Frontend to clang/Basic. This patch adjusts the single file in lldb that uses it to match. Tested on x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D65717 llvm-svn: 367865
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-052-4/+4
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* [lldb][NFC] Fix documentation for ↵Raphael Isemann2019-08-052-4/+3
| | | | | | ClangPersistentVariables::m_next_persistent_variable_id llvm-svn: 367857
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-052-4/+4
| | | | | | assembly format for better readability llvm-svn: 367850
* [lldb][NFC] Clang format GetNextPersistentVariableName signatureRaphael Isemann2019-08-052-2/+2
| | | | llvm-svn: 367843
* [lldb] Move redundant persistent variable counter to ClangPersistentVariablesRaphael Isemann2019-08-054-20/+14
| | | | | | | | | | | | | | | | | Currently Target::m_next_persistent_variable_index is counting up for our persistent variables ($0, $1, ...) but we also have a unused counter that is supposed to do this in ClangPersistentVariables but that stays always at 0 (because we currently increase the target counter when we should increase that unused counter). This patch removes the counter in Target and lets the documented counter in ClangPersistentVariables do the variable counting. Patch *should* be NFC, but it might unexpectedly bring LLDB to new code paths that could contain exciting new bugs to fix. llvm-svn: 367842
* Fix PDB tests after r367820Pavel Labath2019-08-057-6/+8
| | | | | | | | | | | The commit changed Module dumping code to call SymbolFile::Dump directly, which meant that we were no longer showing the plugin name in the output (as that was done in the SymbolVendor). This adds the plugin name printing code to the SymbolFile dump method, and tweak the assertions in the PDB tests to match it correctly. llvm-svn: 367835
* [lldb][NFC] Remove unimplemented ClangExpressionSourceCode::GetNumBodyLinesRaphael Isemann2019-08-051-2/+0
| | | | llvm-svn: 367830
* ObjectFile[ELF]: Refactor gnu_debuglink interfacePavel Labath2019-08-055-92/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove SymbolVendor::GetSymtabPavel Labath2019-08-059-140/+97
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly. All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code. Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65569 llvm-svn: 367820
* Remove usage of usleep in generic codePavel Labath2019-08-055-13/+8
| | | | | | | | This function is not portable, and there are only a handful of usages of it anyway. Replacing it with std::this_thread::sleep_for enables us to get rid of the compatibility code in PosixApi.h. llvm-svn: 367814
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-058-13/+13
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Fix ClangASTContext::CreateParameterDeclaration to not call addDeclShafik Yaghmour2019-08-0210-5/+79
| | | | | | | | | Summary: The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang. Differential Revision: https://reviews.llvm.org/D65414 llvm-svn: 367726
* Use rip-relative addressing in asm testJoseph Tremoulet2019-08-021-1/+1
| | | | | | The absolute form is an error when targeting Darwin. llvm-svn: 367706
* [Formatters] Temporarily disable libc++ std::function formatter due to ↵Shafik Yaghmour2019-08-022-6/+3
| | | | | | | | | | performance issue Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix. Differential Revision: https://reviews.llvm.org/D65666 llvm-svn: 367701
OpenPOWER on IntegriCloud