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
This allows us to collect useful metrics about lldb debugging sessions.
I thought that an example would be better than a thousand words:
Process 19705 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100000fb4 blah`main at blah.c:3
1 int main(void) {
2 int a = 6;
-> 3 return 0;
4 }
(lldb) statistics enable
(lldb) frame var a
(int) a = 6
(lldb) expr a
(int) $1 = 6
(lldb) statistics disable
(lldb) statistics dump
Number of expr evaluation successes : 1
Number of expr evaluation failures : 0
Number of frame var successes : 1
Number of frame var failures : 0
Future improvements might include:
1. Passing a file, or implementing categories. The way this patch has
been implemented is generic enough to allow this to be extended
easily without breaking the grammar.
2. Adding an SBAPI and Python API for use in scripts.
Thanks to Jim Ingham for discussing the design with me.
<rdar://problem/36555975>
Differential Revision: https://reviews.llvm.org/D45547
llvm-svn: 330043
It looks like we introduced isprint8 way back in r169417 to be used on
getopt's short_options, which we sometimes set to values which are out
of range for normal chars to indicate options with no short form.
However, this is not how the function is used in the Args class, where
we explicitly process a string character by character.
This removes the last external dependency from the Args class.
llvm-svn: 329682
Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Args class can be turned
into a lightweight arc+argv wrapper and moved into the lower lldb
layers.
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44306
llvm-svn: 329677
This one will be used to print statistics about lldb sessions
(including, e.g. number of expression evaluation succeeded or
failed). I decided to commit the skeleton first so that we have
a clean reference on how a command should be implemented.
My future commits are going to populate this command and test
it.
<rdar://problem/36555975>
llvm-svn: 328378
It wasn't even registered.
(lldb) apropos args
No commands found pertaining to 'args'. Try 'help' to see
a complete list of debugger commands.
llvm-svn: 328370
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
Host::GetEnvironment returns a StringList, but the interface for
launching a process takes Args. The fact that we use two classes for
representing an environment is not ideal, but for now we should at least
have an easy way to convert between the two.
llvm-svn: 320366
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
The core of this change is the new CommandInterpreter::m_command_state,
which models the state transitions for interactive commands, including
an "interrupted" state transition.
In general, command interruption requires cooperation from the code
executing the command, which needs to poll for interruption requests
through CommandInterpreter::WasInterrupted().
CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs
was likely the longest blocking part.
(ex. target modules dump symtab on a complex binary could take 10+ minutes)
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 315037
The core of this change is the new CommandInterpreter::m_command_state, which
models the state transitions for interactive commands, including an
"interrupted" state transition.
In general, command interruption requires cooperation from the code executing
the command, which needs to poll for interruption requests through
CommandInterpreter::WasInterrupted().
CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs was
likely the longest blocking part. (ex. target modules dump symtab on a
complex binary could take 10+ minutes)
patch by lemo
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 313904
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
Now -shlib flag can be provided alongside with names of symbols files:
(lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so
This is helpful when default matching mechanisms by name and UUID
can't find a module, and the user needs to explicitly specify
which module the given symbol file belongs to.
Differential Revision: https://reviews.llvm.org/D35607
llvm-svn: 308933
The interpreter gets invoked in the sigint handler to cancel
long-running Python operations. That requires the interpreter
lock, but that may be held by the Python operation that's getting
interrupted, so the mutex needs to be recursive.
<rdar://problem/33179086>
llvm-svn: 307942
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
This updates the regular expression used to match host/port pairs for the gdb-remote command to also match IPv6 addresses.
The IPv6 address matcher is very generic and does not really check for structural validity of the address. It turns out that IPv6 addresses are very complicated.
llvm-svn: 301559
The attribute was fairly dubious as: a) we shouldn't tell the compiler
when to inline functions, b) GCC complains that the function may be
not always inlinable.
llvm-svn: 300377
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
Summary:
This patch adds accurate dependency specifications to the mail LLDB libraries and tools.
In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way.
For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up.
Reviewers: labath, zturner
Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell
Differential Revision: https://reviews.llvm.org/D29333
llvm-svn: 293686
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
This patch fixes use of incorrect `%zi` to format a plain `int`, and using
`%llu` to format a `uint64_t`. The fix is to use the new typesafe
`llvm::Formatv` based API.
Differential Revision: https://reviews.llvm.org/D28028
Subscribers: lldb-commits
llvm-svn: 290359
LLDB needs some minor changes to adopt PrettyStackTrace after https://reviews.llvm.org/D27683.
We remove our own SetCrashDescription() function and use LLVM-provided RAII objects instead.
We also make sure LLDB doesn't define __crashtracer_info__ which would collide with LLVM's definition.
Differential Revision: https://reviews.llvm.org/D27735
llvm-svn: 289711
I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
Pavel Labath