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
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
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
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 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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
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
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
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
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
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
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
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
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
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
Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:
Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.
Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.
This patch narrows the contract the CompletionRequest has with the different handlers to:
1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.
Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.
Otherwise this patch just completely hides the internal StringList to the different handlers.
The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.
Reviewers: jingham, davide, labath
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49322
llvm-svn: 338151
Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single CompletionRequest. In some cases we also pass an option
vector/index, but as we don't always have this information, it currently is not part of the
CompletionRequest class.
The constructor of the CompletionRequest is now also more sensible. You only pass the
user input, cursor position and your list of matches to the request and the rest will be
inferred (using the same code we used before to calculate this). You also have to pass these
match window parameters to it, even though they are unused right now.
The patch shouldn't change any behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48976
llvm-svn: 337031
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.
This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D45480
llvm-svn: 330200
Roman Podoliaka