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
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
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
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
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Summary:
At present, several gtests in the lldb open source codebase are using
#include statements rooted at $(SOURCE_ROOT)/${LLDB_PROJECT_ROOT}.
This patch cleans up this directory/include structure for both CMake and
Xcode build systems.
rdar://problem/33835795
Reviewers: zturner, jingham, beanz
Reviewed By: beanz
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D36598
llvm-svn: 314849
Summary:
Fetching an input file required about five lines of code, and this was
repeated in multiple unit tests, with slight variations. Add a helper
function for doing that into the lldbUtilityMocks module (which I rename
to lldbUtilityHelpers to commemorate the fact it includes more than
mocks)
Reviewers: zturner, eugene
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34683
llvm-svn: 306668
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limitation in LLVM's implementation
of home_directory() that LLDB's own implementation had worked
around.
This limitation has been addressed in r298513 on the LLVM side,
so the failing test (which is now unnecessary as the limitation
no longer exists) was removed in r298519, allowing this patch to
be re-submitted without modification.
llvm-svn: 298526
One of the file name templates was occasionally generating the name
"fooa***", which conflicted with the one of the tests expectation that
there is only one item beginning with "fooa".
There doesn't seem to be a good reason for using random file templates
here, so just switch to a fixed set of files to increase
reproducibility.
llvm-svn: 297743
This reverts commit a6a29374662716710f80c8ece96629751697841e.
It has a few compilation failures that I don't have time to fix
at the moment.
llvm-svn: 297589
There were a couple of problems with this function on Windows. Different
separators and differences in how tilde expressions are resolved for
starters, but in addition there was no clear indication of what the
function's inputs or outputs were supposed to be, and there were no tests
to demonstrate its use.
To more easily paper over the differences between Windows paths,
non-Windows paths, and tilde expressions, I've ported this function to use
LLVM-based directory iteration (in fact, I would like to eliminate all of
LLDB's directory iteration code entirely since LLVM's is cleaner / more
efficient (i.e. it invokes fewer stat calls)). and llvm's portable path
manipulation library.
Since file and directory completion assumes you are referring to files and
directories on your local machine, it's safe to assume the path syntax
properties of the host in doing so, so LLVM's APIs are perfect for this.
I've also added a fairly robust set of unit tests. Since you can't really
predict what users will be on your machine, or what their home directories
will be, I added an interface called TildeExpressionResolver, and in the
unit test I've mocked up a fake implementation that acts like a unix
password database. This allows us to configure some fake users and home
directories in the test, so we can exercise all of those hard-to-test
codepaths that normally otherwise depend on the host.
Differential Revision: https://reviews.llvm.org/D30789
llvm-svn: 297585
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
There were a number of issues with the Args class preventing
efficient use of strings and incoporating LLVM's StringRef class.
The two biggest were:
1. Backing memory stored in a std::string, so we would frequently
have to use const_cast to get a mutable buffer for passing to
various low level APIs.
2. backing std::strings stored in a std::list, which doesn't
provide random access.
I wanted to solve these two issues so that we could provide
StringRef access to the underlying arguments, and also a way
to provide range-based access to the underlying argument array
while still providing convenient c-style access via an argv style
const char**.
The solution here is to store arguments in a single "entry" class
which contains the backing memory, a StringRef with precomputed
length, and the quote char. The backing memory is a manually
allocated const char* so that it is not invalidated when the
container is resized, and there is a separate argv array provided
for c-style access.
Differential revision: https://reviews.llvm.org/D25099
llvm-svn: 283157
Also fixed up a couple misbehaving functions. It is perfectly
legal to have env vars with no values (i.e. the '=' and following
need not be present).
llvm-svn: 282171
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.
In the process, I found a few opportunities for adding some
unit tests, so I added those as well.
Tested on Windows, Linux, and OSX.
llvm-svn: 281799
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
A recent refactor had introduced a bug where if you escaped a
character, the rest of the string would get processed incorrectly.
This patch fixes that bug and adds some unit tests for Args.
llvm-svn: 232288
Pavel Labath