| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit 2c7d10c41278181e3e45c68f28b501cd95193a8a.
|
|
Ensure that errors in `frame variable` are reflected in result object.
The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.
This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.
Differential Revision: https://reviews.llvm.org/D116788
|
|
The current help for `frame variable` is somewhat long. Its length, combined
with the few aliases (`var`, `v`, and `vo`) can make the output of `apropos`
redundant and noisy.
This separates out the details into a separate long help.
Differential Revision: https://reviews.llvm.org/D116708
|
|
This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.
This patch modifies the output of "statistics dump" to be able to get stats from the current target. It adds 3 new stats as well. The output of "statistics dump" is now emitted as JSON so that it can be used to track performance and statistics and the output could be used to populate a database that tracks performance. Sample output looks like:
(lldb) statistics dump
{
"expressionEvaluation": {
"failures": 0,
"successes": 0
},
"firstStopTime": 0.34164492800000001,
"frameVariable": {
"failures": 0,
"successes": 0
},
"launchOrAttachTime": 0.31969605400000001,
"targetCreateTime": 0.0040863039999999998
}
The top level keys are:
"expressionEvaluation" which replaces the previous stats that were emitted as plain text. This dictionary contains the success and fail counts.
"frameVariable" which replaces the previous stats for "frame variable" that were emitted as plain text. This dictionary contains the success and fail counts.
"targetCreateTime" contains the number of seconds it took to create the target and load dependent libraries (if they were enabled) and also will contain symbol preloading times if that setting is enabled.
"launchOrAttachTime" is the time it takes from when the launch/attach is initiated to when the first private stop occurs.
"firstStopTime" is the time in seconds that it takes to stop at the first stop that is presented to the user via the LLDB interface. This value will only have meaning if you set a known breakpoint or stop location in your code that you want to measure as a performance test.
This diff is also meant as a place to discuess what we want out of the "statistics dump" command before adding more funcionality. It is also meant to clean up the previous code that was storting statistics in a vector of numbers within the lldb_private::Target class.
Differential Revision: https://reviews.llvm.org/D111686
|
|
|
|
It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.
The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D108510
|
|
This is part 2, covering the commands source.
Some uses remain where it's tricky to see what the
logic is or they are not used with AppendError.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104448
|
|
A long time ago LLDB wanted to start using StringRef instead of
C-Strings/ConstString but was blocked by the fact that the StringRef constructor
that takes a C-string was asserting that the C-string isn't a nullptr. To
workaround this, D24697 introduced a special function called `withNullAsEmpty`
and that's what LLDB (and only LLDB) started to use to build StringRefs from
C-strings.
A bit later it seems that `withNullAsEmpty` was declared too awkward to use and
instead the assert in the StringRef constructor got removed (see D24904). The
rest of LLDB was then converted to StringRef by just calling the now perfectly
usable implicit constructor.
However, all the calls to `withNullAsEmpty` just remained and are now just
strange artefacts in the code base that just look out of place. It's also
curiously a LLDB-exclusive function and no other project ever called it since
it's introduction half a decade ago.
This patch removes all uses of `withNullAsEmpty`. The follow up will be to
remove the function from StringRef.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D102597
|
|
to `thread backtrace -s`
Commands frame select and thread backtrace -s can be completed in the same way.
Moved the dedicated completion of frame select into a common completion and
apply it to the both commands, along with the test modified.
|
|
Summary:
Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are supposed to be ignored by the
rest of the frame recognizer code. 'frame recognizer delete' is supposed to set
that flag. 'frame recognizer clear' however actually deletes all frame
recognizers (so, it doesn't set the flag but directly deletes them from the
list).
The current implementation of this concept is pretty broken. `frame recognizer
delete` sets the flag, but it somehow thinks that the recognizer id is an index
in the recognizer list. That's not true as it's actually just a member of each
recognizer entry. So it actually just sets the `deleted` flag for a random other
recognizer. The tests for the recognizer still pass as `frame recognizer list`
is also broken and just completely ignored the `deleted` flag and lists all
recognizers. Also `frame recognizer delete` just ignores if it can't actually
delete a recognizer if the id is invalid.
I think we can simplify this whole thing by just actually deleting recognizers
instead of making sure all code is actually respecting the `deleted` flag. I
assume the intention of this was to make sure that all recognizers are getting
unique ids over the course of an LLDB session, but as `clear` is actually
deleting them and we keep recycling ids, that didn't really work to begin with.
This patch deletes the `deleted` flag and just actually deletes the stored
recognizer. Also adds the missing error message in case it find a recognizer
with a given id.
Reviewers: mib
Reviewed By: mib
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84404
|
|
Summary:
Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.
This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.
This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).
Reviewers: jingham, mib
Reviewed By: jingham, mib
Subscribers: MrHate, JDevlieghere
Differential Revision: https://reviews.llvm.org/D83757
|
|
values in CommandObjects
Summary:
This replaces the current use of LLDB's own `StringConvert` with LLVM's
`to_integer` which has a less error-prone API and doesn't use special 'error
values' to designate parsing problems.
Where needed I also added missing error handling code that prints a parsing
error instead of continuing with the error value returned from `StringConvert`
(which either gave a cryptic error message or just took the error value
performed an incorrect action with it. For example, `frame recognizer delete -1`
just deleted the frame recognizer at index 0).
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: labath, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D82297
|
|
Summary: Provided tab completion for command `frame recognizer delete`.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81241
|
|
Summary: Provided the tab completion for command `frame select`.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D81177
|
|
|
|
This patch changes the way the StackFrame Recognizers match a certain
frame.
Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).
Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.
rdar://60386577
Differential Revision: https://reviews.llvm.org/D76188
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This reimplements commit 6b2979c12300b90a1e69791d43ee9cff14f4265e and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This reverts commit 1a39f1b966a8d8f15ed0d5a832d5097cccefe93b as
it breaks macOS.
|
|
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
|
|
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
|
|
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
|
|
Summary: This removes most of unnecessary includes in the `source/Commands` directory. This was generated by IWYU and a script that fixed all the bogus reports from IWYU. Patch is tested on Linux and macOS.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71489
|
|
This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.
Differential revision: https://reviews.llvm.org/D71482
|
|
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
|
|
These files had a lot of whitespace errors in them which was a
constant source of merge conflicts downstream.
|
|
the option parser
The problem with r370734 was that it removed the code for resetting the options in
OptionParsingStarting. This caused that once a 'frame select -r ...' command was executed,
we kept the relative index argument for all following 'frame select ...' invocations (even
the ones with an absolute index as they are the same command object). See rdar://55791276.
This relands the patch but keeps the code that resets the command options before execution.
llvm-svn: 373201
|
|
breaks the option parser
This somehow caused that 'frame select X' ends up being interpreted as 'frame select -r 1' when 'up' or 'down'
were run before 'frame select X'. See rdar://55791276.
Partly reverting to unbreak master. The changes that aren't reverted are the generic 'frame select -r' tests
that are obviously NFC and test existing behavior.
llvm-svn: 373194
|
|
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
|
|
llvm-svn: 370734
|
|
target
Summary:
We always have a dummy target, so any error handling regarding a missing dummy target is dead code now.
Also makes the CommandObject methods that return Target& to express this fact in the API.
This patch just for the CommandObject part of LLDB. I'll migrate the rest of LLDB in a follow-up patch that's WIP.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66737
llvm-svn: 369939
|
|
Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).
This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66522
llvm-svn: 369625
|
|
remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
|
|
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
regex.
Differential Revision: https://reviews.llvm.org/D66392
llvm-svn: 369352
|
|
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
|
|
Summary:
Right now our CommandOptions.inc only generates the initializer for the options list but
not the array declaration boilerplate around it. As the array definition is identical for all arrays,
we might as well also let the CommandOptions.inc generate it alongside the initializers.
This patch will also allow us to generate additional declarations related to that option list in
the future (e.g. a enum class representing the specific options which would make our
handling code less prone).
This patch also fixes a few option tables that didn't follow our naming style.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65331
llvm-svn: 367186
|
|
llvm-svn: 367009
|
|
llvm-svn: 366517
|
|
This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
the debugger. I would've preferred to remove the lazy initialization,
however the fact that the scripting language is set after the debugger
is created makes that tricky. So for now this does exactly the same
thing as when it was under the command interpreter. The result is that
this patch is fully NFC.
Differential revision: https://reviews.llvm.org/D61211
llvm-svn: 359354
|
|
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
|
|
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
|
|
llvm-svn: 345694
|
|
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
|
|
llvm-svn: 345688
|
|
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
|
|
llvm-svn: 345680
|
|
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
|
|
Differential Revision: https://reviews.llvm.org/D53010
llvm-svn: 344102
|
|
llvm::ArrayRef
Differential Revision: https://reviews.llvm.org/D49017
llvm-svn: 343130
|
