Commit Graph

2492 Commits

Author SHA1 Message Date
Kazu Hirata 258531b7ac Remove redundant initialization of Optional (NFC) 2022-08-20 21:18:28 -07:00
Kazu Hirata 347c462e97 [lldb] Use Any::has_value instead of ANy::hasValue (NFC) 2022-08-20 07:28:06 -07:00
Michał Górny d6e1e01da9 [lldb] [Core] Harmonize Communication::Read() returns w/ thread
Harmonize the status and error values of Communication::Read() when
running with and without read thread.  Prior to this change, Read()
would return eConnectionStatusSuccess if read thread was enabled
and the read timed out or reached end-of-file, rather than
the respective states that are returned if read thread was disabled.
Now, it correctly returns eConnectionStatusTimedOut
and eConnectionStatusEndOfFile, and sets the error respectively.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D132217
2022-08-19 15:36:03 +02:00
Jonas Devlieghere 11f45f36dc
[lldb] Fetching symbols in the background with dsymForUUID
On macOS, LLDB uses the DebugSymbols.framework to locate symbol rich
dSYM bundles. [1] The framework uses a variety of methods, one of them
calling into a binary or shell script to locate (and download) dSYMs.
Internally at Apple, that tool is called dsymForUUID and for simplicity
I'm just going to refer to it that way here too, even though it can be
be an arbitrary executable.

The most common use case for dsymForUUID is to fetch symbols from the
network. This can take a long time, and because the calls to the
DebugSymbols.framework are blocking, it takes a while to launch the
process. This is expected and therefore many people don't use this
functionality, but instead use add-dsym when they want symbols for a
given frame, backtrace or module. This is a little faster because you're
only fetching symbols for the module you care about, but it's still a
slow, blocking operation.

This patch introduces a hybrid approach between the two. When
symbols.enable-background-lookup is enabled, lldb will do the equivalent
of add-dsym in the background for every module that shows up in the
backtrace but doesn't have symbols for. From the user's perspective
there is no slowdown, because the process launches immediately, with
whatever symbols are available. Meanwhile, more symbol information is
added over time as the background fetching completes.

[1] https://lldb.llvm.org/use/symbols.html

rdar://76241471

Differential revision: https://reviews.llvm.org/D131328
2022-08-15 17:57:24 -07:00
Jonas Devlieghere 8d36a82d0a
[lldb] Flush the global thread pool in Debugger::Terminate
Use the Initialize/Terminate pattern for the global thread pool to make
sure it gets flushed during teardown.

Differential revision: https://reviews.llvm.org/D131407
2022-08-15 17:57:23 -07:00
Slava Gurevich fa5124327a [LLDB][NFC] Reliability Fixes for FormatEntity
- Remove dead code
 - Fix incorrect null-reference check

Differential Revision: https://reviews.llvm.org/D131850
2022-08-15 10:16:47 -07:00
Slava Gurevich 3934a31cfa [LLDB][NFC] Reliability fixes for IOHandlerCursesGUI
- checking retval of function calls
- dead code removal
- null dereference fix

Differential Revision: https://reviews.llvm.org/D131615
2022-08-11 21:10:53 -07:00
Augusto Noronha c6c5944d05 [lldb] Allow DataFileCache to be constructed with a different policy
Differential Revision: https://reviews.llvm.org/D131531
2022-08-11 09:28:30 -07:00
Greg Clayton c012408453 Implement better path matching in FileSpecList::FindCompatibleIndex(...).
Currently a FileSpecList::FindFileIndex(...) will only match the specified FileSpec if:
- it has filename and directory and both match exactly
- if has a filename only and any filename in the list matches

Because of this, we modify our breakpoint resolving so it can handle relative paths by doing some extra code that removes the directory from the FileSpec when searching if the path is relative.

This patch is intended to fix breakpoints so they work as users expect them to by adding the following features:
- allow matches to relative paths in the file list to match as long as the relative path is at the end of the specified path at valid directory delimiters
- allow matches to paths to match if the specified path is relative and shorter than the file paths in the list

This allows us to remove the extra logic from BreakpointResolverFileLine.cpp that added support for setting breakpoints with relative paths.

This means we can still set breakpoints with relative paths when the debug info contains full paths. We add the ability to set breakpoints with full paths when the debug info contains relative paths.

Debug info contains "./a/b/c/main.cpp", the following will set breakpoints successfully:
- /build/a/b/c/main.cpp
- a/b/c/main.cpp
- b/c/main.cpp
- c/main.cpp
- main.cpp
- ./c/main.cpp
- ./a/b/c/main.cpp
- ./b/c/main.cpp
- ./main.cpp

This also ensures that we won't match partial directory names, if a relative path is in the list or is used for the match, things must match at the directory level.

The breakpoint resolving code will now use the new FileSpecList::FindCompatibleIndex(...) function to allow this fuzzy matching to work for breakpoints.

Differential Revision: https://reviews.llvm.org/D130401
2022-08-08 15:20:38 -07:00
Fangrui Song 59d2495fe2 [lldb] LLVM_FALLTHROUGH => [[fallthrough]]. NFC 2022-08-08 11:31:49 -07:00
Alex Langford 1d2a62afaf Re-submit "[lldb] Filter DIEs based on qualified name where possible"
This reverts commit 967df65a36.

This fixes test/Shell/SymbolFile/NativePDB/find-functions.cpp. When
looking up functions with the PDB plugins, if we are looking for a
full function name, we should use `GetName` to populate the `name`
field instead of `GetLookupName` since `GetName` has the more
complete information.
2022-08-04 15:52:27 -07:00
Alex Langford 967df65a36 Revert "[lldb] Filter DIEs based on qualified name where possible"
This reverts commit befa77e59a.

Looks like this broke a SymbolFileNativePDB test. I'll investigate and
resubmit with a fix soon.
2022-08-04 11:52:30 -07:00
Alex Langford befa77e59a [lldb] Filter DIEs based on qualified name where possible
Context:
When setting a breakpoint by name, we invoke Module::FindFunctions to
find the function(s) in question. However, we use a Module::LookupInfo
to first process the user-provided name and figure out exactly what
we're looking for. When we actually perform the function lookup, we
search for the basename. After performing the search, we then filter out
the results using Module::LookupInfo::Prune. For example, given
a:🅱️:foo we would first search for all instances of foo and then filter
out the results to just names that have a:🅱️:foo in them. As one can
imagine, this involves a lot of debug info processing that we do not
necessarily need to be doing. Instead of doing one large post-processing
step after finding each instance of `foo`, we can filter them as we go
to save time.

Some numbers:
Debugging LLDB and placing a breakpoint on
llvm::itanium_demangle::StringView::begin without this change takes
approximately 70 seconds and resolves 31,920 DIEs. With this change,
placing the breakpoint takes around 30 seconds and resolves 8 DIEs.

Differential Revision: https://reviews.llvm.org/D129682
2022-08-04 11:18:08 -07:00
Augusto Noronha 3aef968ec3 [lldb] Allow SymbolTable regex search functions to match mangled name
It may be useful to search symbol table entries by mangled instead
of demangled names. Add this optional functionality in the SymbolTable
functions.

Differential Revision: https://reviews.llvm.org/D130803
2022-08-03 10:55:32 -07:00
Jason Molenda 96d12187b3 Allow firmware binaries to be specified only by load address
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else.  lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.

A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.

Re-landing this with a uuid_is_null() implementation added to
Utility/UuidCompatibility.h for non-Darwin systems.

Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
2022-08-02 14:14:16 -07:00
Jason Molenda 803386da2f Revert "Allow firmware binaries to be specified only by load address"
This reverts commit d8879fba88.

Debian bot failure; I included <uuid/uuid.h> to get uuid_is_null() but
don't get it there.  Will memcmp or whatever & recommit.
2022-08-02 13:53:34 -07:00
Jason Molenda d8879fba88 Allow firmware binaries to be specified only by load address
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else.  lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.

A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.

Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
2022-08-02 13:49:30 -07:00
Martin Storsjö b7c5683fac [lldb] Silence a GCC warning about missing returns after a fully covered switch. NFC. 2022-08-02 10:57:33 +03:00
Greg Clayton 529a3d87a7 [NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.

The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:

ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

Differential Revision: https://reviews.llvm.org/D130549
2022-07-28 13:28:26 -07:00
Slava Gurevich 24301569f0 [LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 3
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com/projects/llvm:

1355854, 1347549, 1316348, 1372028, 1431625,
1315634, 1315637, 1355855, 1364803, 1420505,
1420563, 1420685, 1366014, 1203966, 1204029,
1204031, 1204032, 1328411, 1325969, 1325968,
1374921, 1094809

Differential Revision: https://reviews.llvm.org/D130602
2022-07-27 10:39:49 -07:00
Pavel Labath 1400a3cb8d [lldb] Always use APFloat for FP dumping
The DumpDataExtractor function had two branches for printing floating
point values. One branch (APFloat) was used if we had a Target object
around and could query it for the appropriate semantics. If we didn't
have a Target, we used host operations to read and format the value.

This patch changes second path to use APFloat as well. To make it work,
I pick reasonable defaults for different byte size. Notably, I did not
include x87 long double in that list (as it is ambibuous and
architecture-specific). This exposed a bug where we were printing
register values using the target-less branch, even though the registers
definitely belong to a target, and we had it available. Fixing this
prompted the update of several tests for register values due to slightly
different floating point outputs.

The most dubious aspect of this patch is the change in
TypeSystemClang::GetFloatTypeSemantics to recognize `10` as a valid size
for x87 long double. This was necessary because because sizeof(long
double) on x86_64 is 16 even though it only holds 10 bytes of useful
data. This generalizes the hackaround present in the target-free branch
of the dumping function.

Differential Revision: https://reviews.llvm.org/D129750
2022-07-27 14:30:35 +02:00
Jakob Johnson d36ae4952d Add string conversion for InstructionControlFlowKind enum
Refactor the string conversion of the `lldb::InstructionControlFlowKind` enum out
of `Instruction::Dump` to enable reuse of this logic by the
JSON TraceDumper (to be implemented in separate diff).

Will coordinate the landing of this change with D130320 since there will be a minor merge conflict between
these changes.

Test Plan:
Run unittests
```
> ninja check-lldb
[4/5] Running lldb unit test suite

Testing Time: 10.13s
  Passed: 1084
```

Verify '-k' flag's output
```
(lldb) thread trace dump instructions -k
thread #1: tid = 1375377
  libstdc++.so.6`std::ostream::flush() + 43
    7048: 0x00007ffff7b54dab    return      retq
    7047: 0x00007ffff7b54daa    other       popq   %rbx
    7046: 0x00007ffff7b54da7    other       movq   %rbx, %rax
    7045: 0x00007ffff7b54da5    cond jump   je     0x11adb0                  ; <+48>
    7044: 0x00007ffff7b54da2    other       cmpl   $-0x1, %eax
  libc.so.6`_IO_fflush + 249
    7043: 0x00007ffff7161729    return      retq
    7042: 0x00007ffff7161728    other       popq   %rbp
    7041: 0x00007ffff7161727    other       popq   %rbx
    7040: 0x00007ffff7161725    other       movl   %edx, %eax
    7039: 0x00007ffff7161721    other       addq   $0x8, %rsp
    7038: 0x00007ffff7161709    cond jump   je     0x87721                   ; <+241>
    7037: 0x00007ffff7161707    other       decl   (%rsi)
    7036: 0x00007ffff71616fe    cond jump   je     0x87707                   ; <+215>
    7035: 0x00007ffff71616f7    other       cmpl   $0x0, 0x33de92(%rip)      ; __libc_multiple_threads
    7034: 0x00007ffff71616ef    other       movq   $0x0, 0x8(%rsi)
    7033: 0x00007ffff71616ed    cond jump   jne    0x87721                   ; <+241>
    7032: 0x00007ffff71616e9    other       subl   $0x1, 0x4(%rsi)
    7031: 0x00007ffff71616e2    other       movq   0x88(%rbx), %rsi
    7030: 0x00007ffff71616e0    cond jump   jne    0x87721                   ; <+241>
    7029: 0x00007ffff71616da    other       testl  $0x8000, (%rbx)           ; imm = 0x8000
```

Differential Revision: https://reviews.llvm.org/D130580
2022-07-26 16:09:57 -07:00
Walter Erquinigo 0538e5431a Move GetControlFlowKind's logic to DisassemblerLLVMC.cpp
This diff move the logic of `GetControlFlowKind()` from Disassembler.cpp to DisassemblerLLVMC.cpp.
Here's details:
- Actual logic of GetControlFlowKind() move to `DisassemblerLLVMC.cpp`, and we can check underlying architecture using `DisassemblerScope` there.
- With this change, passing 'triple' to `GetControlFlowKind()` is no more required.

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D130320
2022-07-26 12:05:23 -07:00
Nico Weber 1b4b12a340 Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups
This reverts commit 9429b67b8e.

It broke the build on Windows, see comments on https://reviews.llvm.org/D130309

It also reverts these follow-ups:

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815f4.

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4c2.

Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe877248.
2022-07-23 12:35:48 -04:00
Greg Clayton 9429b67b8e [NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
    ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

Differential Revision: https://reviews.llvm.org/D130309
2022-07-22 10:12:31 -07:00
Kazu Hirata 5cff5142a8 Use value instead of getValue (NFC) 2022-07-15 20:03:13 -07:00
Walter Erquinigo ad7bcda940 [trace] Add a flag to the decoder to output the instruction type
To build complex binding upon instruction trace, additional metadata 'instruction type' is needed.

This diff has followings:
 - Add a flag -k  / --kind for instruction dump
 - Remove SetGranularity and SetIgnoreErros from Trace cursor

Sample output:

```
(lldb) thread trace dump instruction -k
thread #1: tid = 3198805
  libc.so.6`_IO_puts + 356
    2107: 0x00007ffff7163594 (    return)     retq
    2106: 0x00007ffff7163592 (     other)     popq   %r13
    2105: 0x00007ffff7163590 (     other)     popq   %r12
    2104: 0x00007ffff716358f (     other)     popq   %rbp
    2103: 0x00007ffff716358e (     other)     popq   %rbx
    2102: 0x00007ffff716358c (     other)     movl   %ebx, %eax
    2101: 0x00007ffff7163588 (     other)     addq   $0x8, %rsp
    2100: 0x00007ffff7163570 ( cond jump)     je     0x89588                   ; <+344>
    2099: 0x00007ffff716356e (     other)     decl   (%rdx)
    2098: 0x00007ffff7163565 ( cond jump)     je     0x8956e                   ; <+318>
    2097: 0x00007ffff716355e (     other)     cmpl   $0x0, 0x33c02b(%rip)      ; __libc_multiple_threads
    2096: 0x00007ffff7163556 (     other)     movq   $0x0, 0x8(%rdx)
    2095: 0x00007ffff7163554 ( cond jump)     jne    0x89588                   ; <+344>
    2094: 0x00007ffff7163550 (     other)     subl   $0x1, 0x4(%rdx)
    2093: 0x00007ffff7163549 (     other)     movq   0x88(%rbp), %rdx
    2092: 0x00007ffff7163547 ( cond jump)     jne    0x89588                   ; <+344>
    2091: 0x00007ffff7163540 (     other)     testl  $0x8000, (%rbp)           ; imm = 0x8000
    2090: 0x00007ffff716353c (     other)     cmovaq %rax, %rbx
    2089: 0x00007ffff7163535 (     other)     cmpq   $0x7fffffff, %rbx         ; imm = 0x7FFFFFFF
    2088: 0x00007ffff7163530 (     other)     movl   $0x7fffffff, %eax         ; imm = 0x7FFFFFFF
```

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D128477
2022-07-12 16:23:03 -07:00
Zequan Wu b74a01a80b Reland "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."
This reland 227dffd0b6 and
562c3467a6 with failed api tests fixed by keeping
function base file addres in DWARFExpressionList.
2022-07-12 10:54:24 -07:00
Jonas Devlieghere e4c5bca597
Revert "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."
This reverts commit 227dffd0b6 and its
follow up 562c3467a6 because it breaks a
bunch of tests on GreenDragon:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45155/
2022-07-07 16:36:10 -07:00
David Blaikie 6edbde1001 Simplify some AsCString usage that was also explicitly handling default 2022-07-07 20:27:05 +00:00
David Blaikie 856ebe9e82 Retrieve as StringRef since that's how it'll be used 2022-07-07 20:13:36 +00:00
David Blaikie 65cac0ed92 Use StringRef to avoid unnecessary copies into std::strings 2022-07-07 19:50:12 +00:00
Zequan Wu 227dffd0b6 [LLDB][NFC] Decouple dwarf location table from DWARFExpression.
Differential Revision: https://reviews.llvm.org/D125509
2022-07-07 10:26:58 -07:00
Med Ismail Bennani ea8b811bf8 [lldb/Core] Fix finite progress event reporting
This patch should fix event handling for finite progress reports.

Previously, the event handler would get stuck when receiving a finite
progress report, and stop displaying upcoming reports.
This was due to the fact that we were checking if the progress event was
completed by calling `GetCompleted` but returns the completion amount
instead of saying whether it's completed.

That caused the current event id to remain the same, preventing all the
following progress reports to be shown to the user.

This patch also adds some logging to facilitate debugging progress events.

rdar://91788326

Differential Revision: https://reviews.llvm.org/D128768

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-07-05 16:25:40 -07:00
Kazu Hirata 96d1b4ddb2 [lld] Don't use Optional::hasValue (NFC)
This patch replaces x.hasValue() with x where x is contextually
convertible to bool.
2022-06-26 19:29:40 -07:00
Kazu Hirata 3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3.
2022-06-25 11:56:50 -07:00
Kazu Hirata aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Jonas Devlieghere be265d25ca
[lldb] Add support for specifying a log handler
This patch adds a new flag to `log enable`, allowing the user to specify
a custom log handler. In addition to the default (stream) handler, this
allows using the circular log handler (which logs to a fixed size,
in-memory circular buffer) as well as the system log handler (which logs
to the operating system log).

Differential revision: https://reviews.llvm.org/D128323
2022-06-24 18:24:00 -07:00
Jonas Devlieghere 6879391908
[lldb] Replace Host::SystemLog with Debugger::Report{Error,Warning}
As it exists today, Host::SystemLog is used exclusively for error
reporting. With the introduction of diagnostic events, we have a better
way of reporting those. Instead of printing directly to stderr, these
messages now get printed to the debugger's error stream (when using the
default event handler). Alternatively, if someone is listening for these
events, they can decide how to display them, for example in the context
of an IDE such as Xcode.

This change also means we no longer write these messages to the system
log on Darwin. As far as I know, nobody is relying on this, but I think
this is something we could add to the diagnostic event mechanism.

Differential revision: https://reviews.llvm.org/D128480
2022-06-24 09:46:26 -07:00
Walter Erquinigo b8dcd0ba26 [NFC][lldb][trace] Rename trace session to trace bundle
As previously discussed with @jj10306, we didn't really have a name for
the post-mortem (or offline) trace session representation, which is in
fact a folder with a bunch of files. We decided to call this folder
"trace bundle", and the main JSON file in it "trace bundle description
file". This naming is pretty decent, so I'm refactoring all the existing
code to account for that.

Differential Revision: https://reviews.llvm.org/D128484
2022-06-24 08:41:33 -07:00
Jonas Devlieghere 70841b97eb
[lldb] Make thread safety the responsibility of the log handlers
Drop the thread-safe flag and make the locking strategy the
responsibility of the individual log handler.

Previously we got away with a non-thread safe mode because we were using
unbuffered streams that rely on the underlying syscalls/OS for
synchronization. With the introduction of log handlers, we can have
arbitrary logic involved in writing out the logs. With this patch the
log handlers can pick the most appropriate locking strategy for their
particular implementation.

Differential revision: https://reviews.llvm.org/D127922
2022-06-23 09:12:05 -07:00
Jonas Devlieghere 09dea54669
[lldb] Support a buffered logging mode
This patch adds a buffered logging mode to lldb. A buffer size can be
passed to `log enable` with the -b flag. If no buffer size is specified,
logging is unbuffered.

Differential revision: https://reviews.llvm.org/D127986
2022-06-23 09:12:01 -07:00
Kazu Hirata ed8fceaa09 Don't use Optional::getValue (NFC) 2022-06-20 23:35:53 -07:00
Kazu Hirata 5413bf1bac Don't use Optional::hasValue (NFC) 2022-06-20 11:33:56 -07:00
Kazu Hirata aa88161b37 [lldb] Use value_or instead of getValueOr (NFC) 2022-06-19 09:12:01 -07:00
Jonas Devlieghere 91688716ba
[lldb] Fix modernize-use-equals-default warnings (NFC)
Fix modernize-use-equals-default warnings. Because this check is listed
in LLDB's top level .clang-tidy configuration, the check is enabled by
default and the resulting warnings show up in my editor.

I've audited the modified lines. This is not a blind change.
2022-06-17 15:08:02 -07:00
Jonas Devlieghere de74756571
[lldb] Remove LogHandler::Create functions (NFC)
Remove the LogHandler::Create functions. Except for the StreamHandler
they were just forwarding their arguments to std::make_shared.
2022-06-16 21:04:08 -07:00
Jonas Devlieghere 6ff49af33d
[lldb] Introduce the concept of a log handler (NFC)
This patch introduces the concept of a log handlers. Log handlers allow
customizing the way log output is emitted. The StreamCallback class
tried to do something conceptually similar. The benefit of the log
handler interface is that you don't need to conform to llvm's
raw_ostream interface.

Differential revision: https://reviews.llvm.org/D127922
2022-06-16 13:34:28 -07:00
Alvin Wong 25c8a061c5 [lldb] Set COFF module ABI from default triple and make it an option
PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.

This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.

A new setting, `plugin.object-file.pe-coff.abi`,  has been added to
allow overriding this default ABI.

* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D127048
2022-06-09 22:43:33 +03:00
Jason Molenda bd67468645 Check that a FileSpec has a Directory component before using
A follow on to my patch for https://reviews.llvm.org/D126435
hit by an x86_64 linux bot; I assumed that a FileSpec had a
directory component and checked if the first character was a
'~'.  This was not a valid assumption.
2022-05-26 11:12:37 -07:00