Commit Graph

2458 Commits

Author SHA1 Message Date
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
Jason Molenda 8a467284d5 Defer source path remap tilde expansion until source file use
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings.  This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time.  Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.

This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules.  We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.

Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379

(cherry picked from commit c274b6e583)
2022-05-26 11:12:37 -07:00
Jason Molenda 56ac85a20f Revert "Defer source path remap tilde expansion until source file use"
This reverts commit c274b6e583.

The x86_64 debian bot got a failure with this patch,
https://lab.llvm.org/buildbot#builders/68/builds/33078
where
SymbolFile/DWARF/x86/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu1.s
is crashing here -

 #2 0x0000000000425a9f SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f57160e9140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #4 0x00007f570d911e43 lldb_private::SourceManager::GetFile(lldb_private::FileSpec const&) crtstuff.c:0:0
 #5 0x00007f570d914270 lldb_private::SourceManager::DisplaySourceLinesWithLineNumbers(lldb_private::FileSpec const&, unsigned int, unsigned int, unsigned int, unsigned int, char const*, lldb_private::Stream*, lldb_private::SymbolContextList const*) crtstuff.c:0:0
 #6 0x00007f570da662c8 lldb_private::StackFrame::GetStatus(lldb_private::Stream&, bool, bool, bool, char const*) crtstuff.c:0:0

I don't get a failure here my mac, I'll review this method more
closely tomorrow.
2022-05-26 00:46:54 -07:00
Jason Molenda c274b6e583 Defer source path remap tilde expansion until source file use
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings.  This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time.  Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.

This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules.  We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.

Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379
2022-05-26 00:30:12 -07:00
Med Ismail Bennani 051a5ae998 [lldb/Core] Fix "sticky" long progress messages
When the terminal window is too small, lldb would wrap progress messages
accross multiple lines which would break the progress event handling
code that is supposed to clear the message once the progress is completed.

This causes the progress message to remain on the screen, sometimes partially,
which can be confusing for the user.

To fix this issue, this patch trims the progress message to the terminal
width taking into account the progress counter leading the message for
finite progress events and also the trailing `...`.

rdar://91993836

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-05-18 18:22:46 -07:00
Tobias Ribizel b1aed14bfe [llvm][lldb] use FindLibEdit.cmake everywhere
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D124673
2022-05-12 15:59:41 -07:00
Jim Ingham 3339000e0b We don't require users to type out the full context of a function, for
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then compare
the rest of the context that the user provided to make sure it
matches. However, we do this comparison using just a strstr. So for
instance:

break set -n foo::bar

will match not only "a::foo::bar" but "notherfoo::bar". The former is
pretty clearly the user's intent, but I don't think the latter is, and
results in breakpoints picking up too many matches.

This change adds a Language::DemangledNameContainsPath API which can
do a language aware match against the path provided. If the language
doesn't provide this we fall back to the strstr (though that's changed
to StringRef::contains in the patch).

Differential Revision: https://reviews.llvm.org/D124579
2022-05-12 12:39:28 -07:00
Luboš Luňák 20048f3150 [lldb] use one shared ThreadPool and task groups
As a preparation for parallelizing loading of symbols (D122975),
it is necessary to use just one thread pool to avoid using
a thread pool from inside a task of another thread pool.

Differential Revision: https://reviews.llvm.org/D123226
2022-05-04 06:18:20 +02:00
Jonas Devlieghere 3d08c778c0
[lldb] Session transcript should use the async debugger streams
When writing out the session transcript, print output to the
asynchronous debugger stream to prevent it from potentially interleaving
with other output.

Differential revision: https://reviews.llvm.org/D124873
2022-05-03 15:11:57 -07:00
Jeffrey Tan 7b81192d46 Introduce new symbol on-demand for debug info
This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant performance improvement
for application with dynamic linking mode which has large
number of modules.
The feature can be turned on with:
"settings set symbols.load-on-demand true"

The feature works by creating a new SymbolFileOnDemand class for
each module which wraps the actual SymbolFIle subclass as member
variable. By default, most virtual methods on SymbolFileOnDemand are
skipped so that it looks like there is no debug info for that module.
But once the module's debug info is explicitly requested to
be enabled (in the conditions mentioned below) SymbolFileOnDemand
will allow all methods to pass through and forward to the actual SymbolFile
which would hydrate module's debug info on-demand.

In an internal benchmark, we are seeing more than 95% improvement
for a 3000 modules application.

Currently we are providing several ways to on demand hydrate
a module's debug info:
* Source line breakpoint: matching in supported files
* Stack trace: resolving symbol context for an address
* Symbolic breakpoint: symbol table match guided promotion
* Global variable: symbol table match guided promotion

In all above situations the module's debug info will be on-demand
parsed and indexed.

Some follow-ups for this feature:
* Add a command that allows users to load debug info explicitly while using a
  new or existing command when this feature is enabled
* Add settings for "never load any of these executables in Symbols On Demand"
  that takes a list of globs
* Add settings for "always load the the debug info for executables in Symbols
  On Demand" that takes a list of globs
* Add a new column in "image list" that shows up by default when Symbols On
  Demand is enable to show the status for each shlib like "not enabled for
  this", "debug info off" and "debug info on" (with a single character to
  short string, not the ones I just typed)

Differential Revision: https://reviews.llvm.org/D121631
2022-04-26 10:42:06 -07:00
Jonas Devlieghere 99d9c44434
[lldb] Port Process::PrintWarning* to use the new diagnostic events
Port the two Process::PrintWarning functions to use the new diagnostic
events through Debugger::ReportWarning. I kept the wrapper function in
the process, but delegated the work to the Module. Consistent with the
current code, the Module ensures the warning is only printed once per
module.

Differential revision: https://reviews.llvm.org/D123698
2022-04-14 11:00:21 -07:00
Nathan Sidwell 201c4b9cc4 [demangler] Rust demangler buffer return
The rust demangler has some odd buffer handling code, which will copy
the demangled string into the provided buffer, if it will fit.
Otherwise it uses the allocated buffer it made.  But the length of the
incoming buffer will have come from a previous call, which was the
length of the demangled string -- not the buffer size.  And of course,
we're unconditionally allocating a temporary buffer in the first
place.  So we don't actually get buffer reuse, and we get a memcpy in
somecases.

However, nothing in LLVM ever passes in a non-null pointer.  Neither
does anything pass in a status pointer that is then made use of.  The
only exercise these have is in the test suite.

So let's just make the rust demangler have the same API as the dlang
demangler.

Reviewed By: tmiasko

Differential Revision: https://reviews.llvm.org/D123420
2022-04-13 08:50:04 -07:00
Jonas Devlieghere 990d0c7109
[lldb] Print diagnostic prefixes (error, warning) in color
Print diagnostic prefixes (error, warning) in their respective colors
when colors are enabled.
2022-04-12 20:28:29 -07:00
Luboš Luňák 195a8b977e don't extra notify ModulesDidLoad() from LoadModuleAtAddress()
Places calling LoadModuleAtAddress() already call ModulesDidLoad()
after a loop calling LoadModuleAtAddress(), so it's not necessary
to call it from there, and the batched ModulesDidLoad() may be
more efficient than this place calling it one after one.

This also makes the ModuleLoadedNotifys test pass on Linux now that
the duplicates no longer bring down the average of modules notified
per call.

Differential Revision: https://reviews.llvm.org/D123128
2022-04-12 00:36:33 +02:00
Jonas Devlieghere cbcb3bcee3
[lldb] Don't report progress in the REPL
Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you're waiting for the next line to be executed in the REPL.

This patch disables reporting of progress events when in REPL mode.

rdar://91502950

Differential revision: https://reviews.llvm.org/D123426
2022-04-11 13:06:40 -07:00
Luboš Luňák c29a51b3a2 [lldb][gui] remove the "expand" diamond for variables where expanding fails
If the variables view shows a variable that is a struct that has
MightHaveChildren(), the expand diamond is shown, but if trying to expand
it and it's not possible (e.g. incomplete type), remove the expand diamond
to visualize that it can't be in fact expanded. Otherwise it feels kinda
weird that a tree item cannot be expanded even though it "should".

I guess the MightHaveChildren() checking means that GetChildren() may
be expensive, so also do not call it for rows that are not expanded.

Differential Revision: https://reviews.llvm.org/D123008
2022-04-07 21:59:18 +02:00
Luboš Luňák f42f21746c [lldb][gui] handle Ctrl+C to stop a running process
Differential Revision: https://reviews.llvm.org/D123015
2022-04-07 21:58:37 +02:00
Martin Storsjö 6e38824221 [lldb] Silence GCC/glibc warnings about ignoring the return value of write(). NFC.
This matches how another similar warning is silenced in
Host/posix/ProcessLauncherPosixFork.cpp.

Differential Revision: https://reviews.llvm.org/D123205
2022-04-06 22:50:07 +03:00
Martin Storsjö ae2aa2d21b [lldb] Silence GCC warnings about missing returns after fully covered switches. NFC.
This silences warnings like this:

lldb/source/Core/DebuggerEvents.cpp: In member function ‘llvm::StringRef lldb_private::DiagnosticEventData::GetPrefix() const’:
lldb/source/Core/DebuggerEvents.cpp:55:1: warning: control reaches end of non-void function [-Wreturn-type]
   55 | }

Differential Revision: https://reviews.llvm.org/D123203
2022-04-06 22:50:07 +03:00
Greg Clayton b6087ba769 Disable LLDB index cache for .o files with no UUID.
After enabling the LLDB index cache in production we discovered that some distributed build systems play with the modification times of any .o files that were downloaded from the build cache. This was causing the LLDB index cache to read the wrong cache file for files that didn't have a UUID as all of the modfication times were set to the same value by the build system. When new .o files were downloaded, the only unique identifier was the mod time which were all the same, and we would load an older cache for the updated .o file. So disabling caching of files that have no UUIDs for now until we can create a more solid solution.

Differential Revision: https://reviews.llvm.org/D120948
2022-04-05 15:14:36 -07:00
Jonas Devlieghere f2ea125ea0
[lldb] Change CreateMemoryInstance to take a WritableDataBuffer
Change the CreateMemoryInstance interface to take a WritableDataBuffer.

Differential revision: https://reviews.llvm.org/D123073
2022-04-05 13:46:41 -07:00
Jonas Devlieghere fc54427e76
[lldb] Refactor DataBuffer so we can map files as read-only
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

Differential revision: https://reviews.llvm.org/D122856
2022-04-05 13:46:37 -07:00
Pavel Labath e67cee0949 [lldb] Avoid duplicate vdso modules when opening core files
When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso module is
very special, and over the years, we have accumulated various ways to
load it.

In D10800, we added one mechanism for loading it, which took the form of
a generic load-from-memory capability. Unfortunately loading an elf file
from memory is not possible (because the loader never loads the entire
file), and our attempts to do so were causing crashes. So, in D34352, we
partially reverted D10800 and implemented a custom mechanism specific to
the vdso.

Unfortunately, enough of D10800 remained such that, under the right
circumstances, it could end up loading a second (non-functional) copy of
the vdso module. This happened when the process plugin did not support
the extended MemoryRegionInfo query (added in D22219, to workaround a
different bug), which meant that the loader plugin was not able to
recognise that the linux-vdso.so.1 module (this is how the loader calls
it) is in fact the same as the [vdso] module (the name used in
/proc/$PID/maps) we loaded before. This typically happened in a core
file, as they don't store this kind of information.

This patch fixes the issue by completing the revert of D10800 -- the
memory loading code is removed completely. It also reduces the scope of
the hackaround introduced in D22219 -- it isn't completely sound and is
only relevant for fairly old (but still supported) versions of android.

I added the memory loading logic to the wasm dynamic loader, which has
since appeared and is relying on this feature (it even has a test). As
far as I can tell loading wasm modules from memory is possible and
reliable. MachO memory loading is not affected by this patch, as it uses
a completely different code path.

Since the scenarios/patches I described came without test cases, I have
created two new gdb-client tests cases for them. They're not
particularly readable, but right now, this is the best way we can
simulate the behavior (bugs) of a particular dynamic linker.

Differential Revision: https://reviews.llvm.org/D122660
2022-04-05 11:22:37 +02:00
Luboš Luňák 76bc772920 [lldb][gui] make 'step out' step out of the selected frame
Differential Revision: https://reviews.llvm.org/D123001
2022-04-05 08:29:13 +02:00
Luboš Luňák f90fa55569 [lldb][gui] use just '#2' instead of 'frame #2' in the threads/frame view
Since the threads/frame view is taking only a small part on the right side
of the screen, only a part of the function name of each frame is visible.
It seems rather wasteful to spell out 'frame' there when it's obvious
that it is a frame, it's better to use the space for more of the function
name.

Differential Revision: https://reviews.llvm.org/D122998
2022-04-05 08:29:13 +02:00
Luboš Luňák aaca2acd5f [lldb][gui] do not show the help window on first gui startup
It's rather annoying if it's there after every startup,
and that 'Help (F6)' at the top should be enough to help people
who don't know.

Differential Revision: https://reviews.llvm.org/D122997
2022-04-05 08:29:13 +02:00
Luboš Luňák baebf23896 [lldb][gui] underline the current token
Just like the non-gui listing already does.
2022-04-03 17:52:01 +02:00
Luboš Luňák 5e79a00178 [lldb][gui] use symbolic names rather than hardcoded values 2022-04-03 17:52:01 +02:00
Luboš Luňák 5c540c751c [lldb][gui] fix background of syntax-highlighted non-selected PC line
It is the PC line, selected or not, that gets the blue-background
highlight. Without this, a keyword like 'bool' got black background
if the line wasn't selected.
And the blue-background highlight is handled by OutputColoredStringTruncated(),
so no point in setting it explicitly in the calling code.
2022-04-03 17:52:01 +02:00
Luboš Luňák 11b6d2f9cd [lldb][gui] draw highlight for selected line even if empty 2022-04-03 17:52:00 +02:00
Jonas Devlieghere 2165c36be4
[lldb] Return a DataBuffer from FileSystem::CreateDataBuffer (NFC)
The concrete class (DataBufferLLVM) is an implementation detail.
2022-04-01 17:31:20 -07:00
Shafik Yaghmour 24f9a2f53d [LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844
2022-03-31 13:21:49 -07:00
Pavel Labath c484857b2e [lldb] Use =default in the ValueList class 2022-03-30 09:12:59 +02:00
Jonas Devlieghere 2fc38b2b7b
[lldb] Report debugger diagnostics as events
Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.

The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.

Differential revision: https://reviews.llvm.org/D121511
2022-03-16 08:33:01 -07:00
Pavel Labath ccba163d85 [lldb] Change back LLDBLog::Commands->Types in a couple more places
This was inadvertedly changed (bad search&replace) when I was removing
the LLDBLOG macros.
2022-03-16 15:46:17 +01:00