This got lost while iterating on the patch. We need to always move the
cursor to the front of the line so that if something else
(asynchronously) prints to the debugger's output it overwrites the
progress message.
Add a setting to change how progress is shown in a color enabled
terminal. This follows the existing -prefix, -suffix pattern
that's used elsewhere in lldb.
Differential revision: https://reviews.llvm.org/D121062
This patch adds support for showing progress events when using lldb on
the command line. It spawns a separate thread that listens for progress
events and prints them to the debugger's output stream.
It's nothing fancy (yet), for now it just prints the progress message.
If we know the total number of items being processed, we prefix the
message with something like [1/100], similar to ninja's output.
This patch doesn't use any fancy terminal manipulation: it uses a simple
carriage return (\r) to bring the cursor to the front of the line and
vt100 escape codes to clear the (rest) of the line.
Differential revision: https://reviews.llvm.org/D120972
I'm a big fan of the autosuggestion feature but my terminal/color scheme
doesn't display faint any differently than regular lldb output, which
makes the feature a little confusing. This patch add a setting to change
the autosuggestion ANSI escape codes.
For example, to display the autosuggestion in italic, you can add this
to your ~/.lldbinit
settings set show-autosuggestion-ansi-prefix ${ansi.italic}
setting set show-autosuggestion-ansi-suffix ${ansi.normal}
Differential revision: https://reviews.llvm.org/D121064
Accept a function object instead of a raw pointer. This avoids a bunch
of boilerplate typically needed to pass arguments to the thread
functions.
Differential Revision: https://reviews.llvm.org/D120321
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.
Differential revision: https://reviews.llvm.org/D116697
Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will not work.
The problem is that the LLDB create FILE* in lldb.exe and pass it to liblldb.dll which is an object from CRT.
Since the CRT is statically linked each of these module has its own copy of the CRT with it's own global state and the LLDB should not share CRT objects between them.
In this change I moved the logic of creating FILE* out of commands stream from Driver class to SBDebugger.
To do this I added new method: SBError SBDebugger::SetInputStream(SBStream &stream)
Command to build the LLDB:
cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;libcxx" -DLLVM_USE_CRT_RELEASE="MT" -DLLVM_USE_CRT_MINSIZEREL="MT" -DLLVM_USE_CRT_RELWITHDEBINFO="MT" -DP
YTHON_HOME:FILEPATH=C:/Python38 -DCMAKE_C_COMPILER:STRING=cl.exe -DCMAKE_CXX_COMPILER:STRING=cl.exe ../llvm
Command which will fail:
lldb.exe -o help
See discord discussion for more details: https://discord.com/channels/636084430946959380/636732809708306432/854629125398724628
This revision is for the further discussion.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104413
[NFC] As part of using inclusive language within the llvm project, this patch
replaces master in these comments.
Reviewed By: clayborg, JDevlieghere
Differential Revision: https://reviews.llvm.org/D114123
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.
In order to future-proof the code for the GDB variant:
1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.
2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.
3. Use the intersection of all three flags when matching against
the three possible values.
This commit does not change the actual bits used by LLDB.
Differential Revision: https://reviews.llvm.org/D106984
Previously, when `interpreter.save-session-on-quit` was enabled, lldb
would save the session transcript only when running the `quit` command.
This patch changes that so the transcripts are saved when the debugger
object is destroyed if the setting is enabled.
rdar://72902650
Differential Revision: https://reviews.llvm.org/D105038
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running operations can make a debug session appear to be doing nothing even though a lot of work is going on inside LLDB. This patch adds a public API to allow clients to listen to debugger events that report progress and will allow UI to create an activity window or display that can show users what is going on and keep them informed of expensive operations that are going on inside LLDB.
Differential Revision: https://reviews.llvm.org/D97739
This patch replaces the static large function threshold variable with a
global debugger setting (`stop-disassembly-max-size`).
The default threshold is now set to 32KB (instead of 8KB) and can be modified.
rdar://74726362
Differential Revision: https://reviews.llvm.org/D97486
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The Debugger didn't take the Process's run lock, that causes deadlocks and races
after applying https://reviews.llvm.org/D92164 revision. Since ExecutionContextRef
does the same job correctly, Debugger::GetSelectedExecutionContext just can use it
to build execution context upon the selected target.
Factor out dummy target creation from CreateTargetInternal.
This makes it impossible for dummy target creation to accidentally fail
due to too-strict checking in one of the CreateTargetInternal overloads.
Testing: check-lldb
rdar://70630655
Differential Revision: https://reviews.llvm.org/D90872
We didn't do anything with the llvm::Error we get from `Open`, so when we end up in the
error case we just crash due to the llvm::Error sanity check. Also add the missing newline
behind the error message so it no longer messes with the next (lldb) prompt.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D85970
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
This reverts commit 246afe0cd1. This broke
the following tests on Linux it seems:
lldb-api :: commands/expression/multiline-completion/TestMultilineCompletion.py
lldb-api :: iohandler/completion/TestIOHandlerCompletion.py
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
This replaces the (only) call to llvm::sys::fs::openFileForWrite with
FileSystem::Open. This guarantees that we include log files in the
reproducers.
Differential revision: https://reviews.llvm.org/D81499
Summary:
The comment in the Editine.h header made it sound like editline was
just unable to handle terminal resizing. We were not ever telling
editline that the terminal had changed size, which might explain why
it wasn't working.
This patch threads a `TerminalSizeChanged()` callback through the
IOHandler and invokes it from the SIGWINCH handler in the driver. Our
`Editline` class already had a `TerminalSizeChanged()` method which
was invoked only when editline was configured.
This patch also changes `Editline` to not apply the changes right away
in `TerminalSizeChanged()`, but instead defer that to the next
character read. During my testing, it happened once that the signal
was received while our `ConnectionFileDescriptor::Read` was allocating
memory. As `el_resize` seems to allocate memory too, this crashed.
Reviewers: labath, teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79654
Summary:
LLDB memory-maps large source files, and at the same time, caches
all source files in the Source Cache.
On Windows, memory-mapped source files are not writeable, causing
bad user experience in IDEs (such as errors when saving edited files).
IDEs should have the ability to disable the Source Cache at LLDB
startup, so that users can edit source files while debugging.
Bug: llvm.org/PR45310
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76804
Highlight the color marker similar to what we do for the column marker.
The default color matches the color of the current PC marker (->) in the
default disassembly format.
Differential revision: https://reviews.llvm.org/D75070
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
The way the IO handlers are currently managed by the debugger is wrong. The
implementation lacks proper synchronization between RunIOHandlerSync and
RunIOHandlers. The latter is meant to be run by the "main thread", while the
former is meant to be run synchronously, potentially from a different thread.
Imagine a scenario where RunIOHandlerSync is called from a different thread
than RunIOHandlers. Both functions manipulate the debugger's IOHandlerStack.
Although the push and pop operations are synchronized, the logic to activate,
deactivate and run IO handlers is not.
While investigating PR44352, I noticed some weird behavior in the Editline
implementation. One of its members (m_editor_status) was modified from another
thread. This happened because the main thread, while running RunIOHandlers
ended up execution the IOHandlerEditline created by the breakpoint callback
thread. Even worse, due to the lack of synchronization within the IO handler
implementation, both threads ended up executing the same IO handler.
Most of the time, the IO handlers don't need to run synchronously. The
exception is sourcing commands from external files, like the .lldbinit file.
I've added a (recursive) mutex to prevent another thread from messing with the
IO handlers wile another thread is running one synchronously. It has to be
recursive, because we might have to source another file when encountering a
command source in the original file.
Differential revision: https://reviews.llvm.org/D72748
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
Rather than holding on to one script interpreter, it should be possible
to request a script interpreter for a specific scripting language. The
GetScriptInterpreter method now takes an optional scripting language
argument.
(NFC)
Summary:
ScriptInterpreterPython needs to save and restore sys.stdout and
friends when LLDB runs a python script.
It currently does this using FILE*, which is not optimal. If
whatever was in sys.stdout can not be represented as a FILE*, then
it will not be restored correctly when the script is finished.
It also means that if the debugger's own output stream is not
representable as a file, ScriptInterpreterPython will not be able
to redirect python's output correctly.
This patch updates ScriptInterpreterPython to represent files with
lldb_private::File, and to represent whatever the user had in
sys.stdout as simply a PythonObject.
This will make lldb interoperate better with other scripts or programs
that need to manipulate sys.stdout.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68962
llvm-svn: 374964
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
Summary:
Add new methods to SBDebugger to set IO files as SBFiles instead of
as FILE* streams.
In future commits, the FILE* methods will be deprecated and these
will become the primary way to set the debugger I/O streams.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68181
llvm-svn: 373563
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
ResetOutputFileHandle() isn't being used by anything. Also it's using
FILE*, which is something we should be doing less of. Remove it.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D68001
llvm-svn: 372800
Summary:
We got a radar that printing small floats is not very user-friendly in LLDB as we print them with up to
100 leading zeroes before starting to use scientific notation. This patch changes this by already using
scientific notation when we hit 6 padding zeroes by default and moves this value into a target setting
so that users can just set this number back to 100 if they for some reason preferred the old behaviour.
This new setting is influencing how we format data, so that's why we have to reset the data visualisation
cache when it is changed.
Note that we have always been using scientific notation for large numbers because it seems that
the LLVM implementation doesn't support printing out the padding zeroes for them. I would have fixed
that if it was trivial, but looking at the LLVM implementation for this it seems that this is not as trivial
as it sounds. I would say we look into this if we ever get a bug report about someone wanting to have
a large amount of trailing zeroes in their numbers instead of using scientific notation.
Fixes rdar://39744137
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67001
llvm-svn: 370880
Summary:
We should always have a dummy target, so we might as well construct it directly when we create a Debugger object.
The idea is that if this patch doesn't cause any problems that we can get rid of all the logic
that handles situations where we don't have a dummy target (as all that code is currently
untested as there seems to be no way to have no dummy target in LLDB).
Reviewers: labath, jingham
Reviewed By: labath, jingham
Subscribers: jingham, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66581
llvm-svn: 369885
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
This reapplies r369690 with a previously missing constructor for LanguageSet.
llvm-svn: 369710
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.
In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.
Differential Revision: https://reviews.llvm.org/D66546
<rdar://problem/54471165>
llvm-svn: 369690
While generating the Doxygen I noticed this lone namespace that has one
class and one function in it. This moves them into lldb_private.
llvm-svn: 369485
Jonas Devlieghere