summaryrefslogtreecommitdiffstats
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFC] Remove unused functionJordan Rupprecht2019-08-141-5/+0
| | | | llvm-svn: 368904
* [DebugLine] Improve path handling.Jonas Devlieghere2019-08-141-12/+11
| | | | | | | | | | | | | | | | | After switching over LLDB's line table parser to libDebugInfo, we noticed two regressions on the Windows bot. The problem is that when obtaining a file from the line table prologue, we append paths without specifying a path style. This leads to incorrect results on Windows for debug info containing Posix paths: 0x0000000000201000: /tmp\b.c, is_start_of_statement = TRUE This patch is an attempt to fix that by guessing the path style whenever possible. Differential revision: https://reviews.llvm.org/D66227 llvm-svn: 368879
* Revert "Minidump/Windows: Fix module lookup"Pavel Labath2019-08-141-1/+0
| | | | | | | | | | | Although there is nothing wrong with this patch, the test added here uncovers a problem in other parts of the code which cause the test to fail when running under asan. Reverting the patch until I can fix the underlying issue(s). This reverts commit r368416. llvm-svn: 368838
* [API] Have SBCommandReturnObject::GetOutput/Error return "" instead of nullptrPavel Labath2019-08-141-7/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: It seems this was an unintended side-effect of D26698. AFAICT, these functions did return an empty string before that patch, and the patch contained code which attempted to ensure that, but those efforts were negated by ConstString::AsCString, which by default returns a nullptr even for empty strings. This patch: - fixes the GetOutput/Error methods to really return empty strings - adds and explicit test for that - removes a workaround in lldbtest.py, which was masking this problem from our other tests Reviewers: jingham, clayborg Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D65739 llvm-svn: 368806
* [lldb] Reinstate original guard variable checkRaphael Isemann2019-08-141-9/+5
| | | | | | | | | | The isGuardVariableSymbol option for ignoring Microsoft's ABI was originally added to get the bots green, but now that we found the actual issue (that we checked for prefix instead of suffix in the MS ABI check), we should be able to properly implement the guard variable check without any strange Microsoft exceptions. llvm-svn: 368802
* Fix warning: suggest braces around initialization of subobjectJonas Devlieghere2019-08-141-5/+7
| | | | | | This patch adds braces to the DEFINE_XMM macro. llvm-svn: 368782
* Enable lldb-server on WindowsAaron Smith2019-08-133-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit contains three small changes to enable lldb-server on Windows. - Add lldb-server for Windows to the build - Disable pty redirection on Windows for the initial lldb-server bring up - Add a support to get the parent pid for a process on Windows - Ifdef some signals which aren't supported on Windows Thanks to Hui Huang for the help with this patch! Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61686 llvm-svn: 368774
* [DebugLine] Be more robust in geussing the path styleJonas Devlieghere2019-08-131-3/+9
| | | | | | | | My previous change didn't fix the Windows bot. This patch is an attempt to make guessing the path style more robust by first looking at the compile dir and falling back to the actual file if that's unsuccessful. llvm-svn: 368772
* Initial support for native debugging of x86/x64 Windows processesAaron Smith2019-08-1320-3/+2899
| | | | | | | | | | | | | | | | Summary: Thanks to Hui Huang and the reviewers for all the help with this patch. Reviewers: labath, Hui, jfb, clayborg, amccarth Reviewed By: labath Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D63165 llvm-svn: 368759
* [DWARF] Guess the path styleJonas Devlieghere2019-08-131-2/+6
| | | | | | Try to guess the FileSpec path style before defaulting to native. llvm-svn: 368746
* [DWARF} Use LLVM's debug line parser in LLDB.Jonas Devlieghere2019-08-135-1208/+179
| | | | | | | | | | | | | | | | The line number table header was substantially revised in DWARF 5 and is not fully supported by LLDB's current debug line implementation. This patch replaces the LLDB debug line parser with its counterpart in LLVM. This was possible because of the limited contact surface between the code to parse the DWARF debug line section and the rest of LLDB. We pay a small cost in terms of performance and memory usage. This is something we plan to address in the near future. Differential revision: https://reviews.llvm.org/D62570 llvm-svn: 368742
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-138-483/+574
| | | | | | | | | | Summary: Ideally CompilerType would have no knowledge of clang or any individual TypeSystem. Decoupling clang is relatively straightforward. Differential Revision: https://reviews.llvm.org/D66102 llvm-svn: 368741
* [lldb] Fix Microsoft guard variable detectionRaphael Isemann2019-08-131-1/+1
| | | | | | | Apparently we need to check for a suffix, not a prefix. This broke probably broke expression evaluation on Windows. llvm-svn: 368695
* [lldb] Reland "Refactor guard variable checks in IRForTarget"Raphael Isemann2019-08-131-14/+19
| | | | | | | | It seems the broken guard variable check for Windows was a feature(TM) and not a bug, so let's keep add a flag to the guard check that keeps the old behavior in the places where we ignored guard variables before. llvm-svn: 368688
* [Symbol] Remove redundant includeAlex Langford2019-08-131-1/+0
| | | | llvm-svn: 368638
* [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.Davide Italiano2019-08-124-6/+7
| | | | llvm-svn: 368620
* Revert "[lldb] Refactor guard variable checks in IRForTarget"Stella Stamenova2019-08-121-12/+12
| | | | | | This reverts commit 94fbbf712e906464f5f3abbeabcfcbc05d5352ec. llvm-svn: 368616
* Revert "[lldb] Fix dynamic_cast by no longer failing on variable without ↵Stella Stamenova2019-08-121-1/+7
| | | | | | | | metadata" This reverts commit b448d1bf212219febbb182d00c210bad1bd25e7f. llvm-svn: 368615
* [Symbol] GetTypeBitAlign() should return None in case of failure.Davide Italiano2019-08-124-14/+23
| | | | | | | | | | | | | | | | Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
* [lldb] Remove undocumented return value from DiagnosticManager::PutStringRaphael Isemann2019-08-121-4/+3
| | | | | | | | | | | The returned value is currently unused. It also seems to imply that it somehow represents 'printf-style' the number of characters/bytes written to some output stream (which is incorrect, as we only know the actual size of the written message when we have rendered it, e.g. via GetString and DiagnosticManagers have no associated output stream). llvm-svn: 368577
* [lldb] Fix dynamic_cast by no longer failing on variable without metadataRaphael Isemann2019-08-101-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated. This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be variables without associated metadata. As there are no variables for these internal variables, this is actually not an error and dynamic_cast would work fine if we didn't throw this error. This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it harder to diagnose any missing metadata errors. This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature. Fixes rdar://10813639 Reviewers: davide, labath Reviewed By: labath Subscribers: friss, labath, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65932 llvm-svn: 368511
* Small format fixHaibo Huang2019-08-091-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D66034 llvm-svn: 368497
* Detects whether RESOURCE_TYPE_IO is defined.Haibo Huang2019-08-091-0/+3
| | | | | | | | | | | | | | Summary: This fixes lldb build on macOS SDK prior to 10.12. Reviewers: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66034 llvm-svn: 368496
* [lldb][NFC] Assert on invalid cursors positions when creating CompletionRequestRaphael Isemann2019-08-091-0/+1
| | | | | | Before we just triggered undefined behavior on invalid positions. llvm-svn: 368444
* [lldb][NFC] Remove unused IRForTarget::BuildRelocationRaphael Isemann2019-08-092-36/+0
| | | | llvm-svn: 368442
* [lldb][NFC] Unify InstrList typedef in IRForTargetRaphael Isemann2019-08-091-6/+2
| | | | llvm-svn: 368425
* [lldb][NFC] Fix warning about missing switch casesRaphael Isemann2019-08-091-0/+14
| | | | | | | | | | These types were recently added in D62960 but it seems the patch didn't consider LLDB which causes a bunch of compiler warnings about missing enum values. It seems this feature isn't fully implemented yet, so I don't think we can write any test for this. For now lets just add the missing types to our usual list of unsupported types. llvm-svn: 368424
* [lldb] Refactor guard variable checks in IRForTargetRaphael Isemann2019-08-091-12/+12
| | | | | | | | Not NFC as this will probably fix a wrong guard variable check on Windows. Not sure though what Windows test can now be safely enabled. llvm-svn: 368417
* Minidump/Windows: Fix module lookupPavel Labath2019-08-091-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: When opening a minidump, we were failing to find an executable because we were searching for i386-unknown-windows, whereas we recognize the pe/coff files as i386-pc-windows. This fixes the triple computation code in the minidump parser to match pe/coff, and adds an appropriate test. NB: I'm not sure setting the vendor to "pc" is really correct for arm(64) windows, but right now that seems to match what we do in the pe/coff case (ArchSpec.cpp:935). Reviewers: clayborg, amccarth Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D65955 llvm-svn: 368416
* [lldb][NFC] Clean up logging in IRForTargetRaphael Isemann2019-08-091-167/+100
| | | | llvm-svn: 368415
* [lldb][NFC] Remove last C string uses from IRForTargetRaphael Isemann2019-08-091-10/+8
| | | | llvm-svn: 368406
* [lldb][NFC] Use range-based for-loops in IRForTargetRaphael Isemann2019-08-091-108/+40
| | | | llvm-svn: 368405
* [lldb][NFC] Modernize IRForTarget::CreateResultVariableRaphael Isemann2019-08-081-21/+20
| | | | llvm-svn: 368359
* [lldb][NFC] Move to StringRef in some places in IRForTargetRaphael Isemann2019-08-081-37/+32
| | | | llvm-svn: 368353
* [lldb] Fix HAVE_LIBCOMPRESSIONHaibo Huang2019-08-082-4/+2
| | | | | | | | | | | | | | | | Summary: This test doesn't make sense. Change to be consistent with what we did in GDBRemoteCommunication.cpp. Reviewers: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65965 llvm-svn: 368352
* [lldb][NFC] Directly use StringRef instead of temporary std::stringRaphael Isemann2019-08-081-13/+12
| | | | llvm-svn: 368346
* SymbolFileDWARF: Unconditionally scan through clang modules. NFCishAdrian Prantl2019-08-081-3/+7
| | | | | | | | | | | | | When looking up a type by name, also scan through any referenced Clang modules regardsless of whether a type with this name has been found. This is NFCish (= a potential performance regression) for Clang projects, but necessary in mixed Swift and Objective-C projects (and tested in swift-lldb). This only affects projects compiled with -gmodules that were not run through dsymutil. llvm-svn: 368345
* Fix a comment which was incorrect.Jim Ingham2019-08-081-1/+1
| | | | llvm-svn: 368340
* Remove unused and undocumented data_offset parameter (NFC)Adrian Prantl2019-08-0810-20/+19
| | | | | | | | | Value::GetValueAsData() takes an undocumented parameter called data_offset that is always 0. Differential Revision: https://reviews.llvm.org/D65910 llvm-svn: 368330
* [lldb][NFC] Simplify return in MaybeHandleVariableRaphael Isemann2019-08-081-9/+4
| | | | | | This function anyway returns true, no need to do this extra work. llvm-svn: 368309
* Fix LLDB_CONFIGURATION_DEBUG builds for the GetSymbolVendor removalPavel Labath2019-08-081-6/+2
| | | | | | fix one usage that is ifdefed-out in non-debug builds. llvm-svn: 368279
* Remove Module::GetSymbolVendorPavel Labath2019-08-082-32/+19
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymbolVendor function, and the various mentions of the SymbolVendor in the Module class. The implementation of GetSymbolVendor is "inlined" into the GetSymbolFile class which I created earlier. After this patch, the SymbolVendor class still exists inside the Module object, but only as an implementation detail -- a fancy holder for the SymbolFile. That will be removed in the next patch. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D65864 llvm-svn: 368263
* [Materializer] Remove wrong SetSizeAndAlignmentFromType().Davide Italiano2019-08-081-14/+0
| | | | | | | | | | | | This function is unused. It's also wrong, because it computes the size and the alignment of the type without asking the runtime, so it doesn't work for any language that has one (e.g. swift). One could consider re-implementing this passing an execution scope context, and modifying GetTypeBitAlign() to do the right thing, but given there are no uses, it's not really useful. llvm-svn: 368249
* [Utility] Remove unused function 'GetMatchSpanningIndices'Jonas Devlieghere2019-08-081-17/+0
| | | | llvm-svn: 368243
* Adjust a ValueObjectChild's offset when the child is a bitfieldAdrian Prantl2019-08-071-0/+24
| | | | | | | | | | | | | | | | | | If a bitfield doesn't fit into the child_byte_size'd window at child_byte_offset, move the window forward until it fits. The problem here is that Value has no notion of bitfields and thus the Value's DataExtractor is sized like the bitfields CompilerType; a sequence of bitfields, however, can be larger than their underlying type. This was not in the big-endian-derived DWARF 2 bitfield attributes because their offsets were counted from the end of the window, so they always fit. rdar://problem/53132189 Differential Revision: https://reviews.llvm.org/D65492 llvm-svn: 368226
* [CommandObject] Remove unused functionJonas Devlieghere2019-08-071-2/+0
| | | | llvm-svn: 368208
* [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-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-071-1/+2
| | | | | | | | | | | | | | | | | | 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-071-2/+2
| | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud