2017-10-31 21:23:19 +08:00
|
|
|
set(LLDB_SYSTEM_LIBS)
|
|
|
|
|
2019-03-30 01:47:26 +08:00
|
|
|
list(APPEND LLDB_SYSTEM_LIBS ${system_libs})
|
2017-10-31 21:23:19 +08:00
|
|
|
|
2019-03-30 01:47:26 +08:00
|
|
|
if (CMAKE_SYSTEM_NAME MATCHES "Windows")
|
|
|
|
list(APPEND LLDB_SYSTEM_LIBS ws2_32 rpcrt4)
|
|
|
|
endif ()
|
2017-10-31 21:23:19 +08:00
|
|
|
|
|
|
|
if (NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB )
|
|
|
|
list(APPEND LLDB_SYSTEM_LIBS atomic)
|
|
|
|
endif()
|
|
|
|
|
2013-09-25 18:37:32 +08:00
|
|
|
add_lldb_library(lldbUtility
|
2017-11-14 00:16:33 +08:00
|
|
|
ArchSpec.cpp
|
2018-04-18 02:53:35 +08:00
|
|
|
Args.cpp
|
2017-03-07 02:34:25 +08:00
|
|
|
Baton.cpp
|
2018-12-14 23:59:49 +08:00
|
|
|
Broadcaster.cpp
|
2017-06-27 18:33:14 +08:00
|
|
|
Connection.cpp
|
2017-02-03 05:39:50 +08:00
|
|
|
ConstString.cpp
|
Refactoring for for the internal command line completion API (NFC)
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
2018-07-03 05:29:56 +08:00
|
|
|
CompletionRequest.cpp
|
2017-03-04 09:30:05 +08:00
|
|
|
DataBufferHeap.cpp
|
|
|
|
DataBufferLLVM.cpp
|
|
|
|
DataEncoder.cpp
|
|
|
|
DataExtractor.cpp
|
Add Utility/Environment class for handling... environments
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
2018-01-10 19:57:31 +08:00
|
|
|
Environment.cpp
|
2018-12-14 23:59:49 +08:00
|
|
|
Event.cpp
|
2017-03-23 02:40:07 +08:00
|
|
|
FileSpec.cpp
|
2017-06-27 18:33:14 +08:00
|
|
|
IOObject.cpp
|
2015-02-10 08:47:43 +08:00
|
|
|
JSON.cpp
|
2015-03-05 07:19:36 +08:00
|
|
|
LLDBAssert.cpp
|
2018-12-14 23:59:49 +08:00
|
|
|
Listener.cpp
|
2017-03-04 04:56:28 +08:00
|
|
|
Log.cpp
|
|
|
|
Logging.cpp
|
2015-03-19 05:31:45 +08:00
|
|
|
NameMatches.cpp
|
Move ProcessInfo from Host to Utility.
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
2019-03-05 05:51:03 +08:00
|
|
|
ProcessInfo.cpp
|
2018-08-07 19:07:21 +08:00
|
|
|
RegisterValue.cpp
|
2017-02-03 05:39:50 +08:00
|
|
|
RegularExpression.cpp
|
2018-11-14 03:18:16 +08:00
|
|
|
Reproducer.cpp
|
2019-02-06 02:46:36 +08:00
|
|
|
ReproducerInstrumentation.cpp
|
2018-08-07 19:07:21 +08:00
|
|
|
Scalar.cpp
|
2016-08-11 06:43:48 +08:00
|
|
|
SelectHelper.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
SharingPtr.cpp
|
2018-08-07 19:07:21 +08:00
|
|
|
State.cpp
|
2017-05-12 12:51:55 +08:00
|
|
|
Status.cpp
|
2017-02-03 05:39:50 +08:00
|
|
|
Stream.cpp
|
2017-03-07 02:34:25 +08:00
|
|
|
StreamCallback.cpp
|
|
|
|
StreamGDBRemote.cpp
|
2017-02-03 05:39:50 +08:00
|
|
|
StreamString.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
StringExtractor.cpp
|
|
|
|
StringExtractorGDBRemote.cpp
|
2014-08-08 04:48:39 +08:00
|
|
|
StringLexer.cpp
|
2017-03-22 02:25:04 +08:00
|
|
|
StringList.cpp
|
2017-06-27 18:45:31 +08:00
|
|
|
StructuredData.cpp
|
2017-03-13 08:41:01 +08:00
|
|
|
TildeExpressionResolver.cpp
|
2017-06-29 22:32:17 +08:00
|
|
|
Timer.cpp
|
2017-03-07 02:34:25 +08:00
|
|
|
UserID.cpp
|
2019-03-05 02:48:00 +08:00
|
|
|
UserIDResolver.cpp
|
2015-01-07 07:38:24 +08:00
|
|
|
UriParser.cpp
|
2017-03-04 09:28:55 +08:00
|
|
|
UUID.cpp
|
2017-02-17 03:38:21 +08:00
|
|
|
VASprintf.cpp
|
2017-03-07 02:34:25 +08:00
|
|
|
VMRange.cpp
|
2017-02-01 04:43:05 +08:00
|
|
|
|
|
|
|
LINK_LIBS
|
2017-10-31 21:23:19 +08:00
|
|
|
${LLDB_SYSTEM_LIBS}
|
|
|
|
# lldbUtility does not depend on other LLDB libraries
|
2017-02-01 04:43:05 +08:00
|
|
|
|
|
|
|
LINK_COMPONENTS
|
2017-06-07 11:48:56 +08:00
|
|
|
BinaryFormat
|
2017-02-01 04:43:05 +08:00
|
|
|
Support
|
2013-09-25 18:37:32 +08:00
|
|
|
)
|