[lldb][NFC] Fix all formatting errors in .cpp file headers
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
2020-01-24 15:23:27 +08:00
|
|
|
//===-- SBLaunchInfo.cpp --------------------------------------------------===//
|
2015-02-05 07:19:15 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-02-05 07:19:15 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/API/SBLaunchInfo.h"
|
2022-01-20 03:38:26 +08:00
|
|
|
#include "lldb/Utility/Instrumentation.h"
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2020-03-21 10:31:33 +08:00
|
|
|
#include "lldb/API/SBEnvironment.h"
|
2021-03-24 00:22:07 +08:00
|
|
|
#include "lldb/API/SBError.h"
|
2015-02-05 07:19:15 +08:00
|
|
|
#include "lldb/API/SBFileSpec.h"
|
|
|
|
#include "lldb/API/SBListener.h"
|
2021-03-24 00:22:07 +08:00
|
|
|
#include "lldb/API/SBStream.h"
|
|
|
|
#include "lldb/API/SBStructuredData.h"
|
|
|
|
#include "lldb/Core/StructuredDataImpl.h"
|
Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to Host
Summary:
These classes describe the details of the process we are about to
launch, and so they are naturally used by the launching code in the Host
module. Previously they were present in Target because that is the most
important (but by far not the only) user of the launching code.
Since the launching code has other customers, must of which do not care
about Targets, it makes sense to move these classes to the Host layer,
next to the launching code.
This move reduces the number of times that Target is included from host
to 8 (it used to be 14).
Reviewers: zturner, clayborg, jingham, davide, teemperor
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56602
llvm-svn: 353047
2019-02-04 22:28:08 +08:00
|
|
|
#include "lldb/Host/ProcessLaunchInfo.h"
|
2015-02-05 07:19:15 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
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
|
|
|
class lldb_private::SBLaunchInfoImpl : public ProcessLaunchInfo {
|
|
|
|
public:
|
2022-01-03 14:44:15 +08:00
|
|
|
SBLaunchInfoImpl() : m_envp(GetEnvironment().getEnvp()) {}
|
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
|
|
|
|
|
|
|
const char *const *GetEnvp() const { return m_envp; }
|
|
|
|
void RegenerateEnvp() { m_envp = GetEnvironment().getEnvp(); }
|
|
|
|
|
|
|
|
SBLaunchInfoImpl &operator=(const ProcessLaunchInfo &rhs) {
|
|
|
|
ProcessLaunchInfo::operator=(rhs);
|
|
|
|
RegenerateEnvp();
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
Environment::Envp m_envp;
|
|
|
|
};
|
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
SBLaunchInfo::SBLaunchInfo(const char **argv)
|
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
|
|
|
: m_opaque_sp(new SBLaunchInfoImpl()) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, argv);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->GetFlags().Reset(eLaunchFlagDebug | eLaunchFlagDisableASLR);
|
|
|
|
if (argv && argv[0])
|
|
|
|
m_opaque_sp->GetArguments().SetArguments(argv);
|
|
|
|
}
|
|
|
|
|
2020-01-29 08:44:30 +08:00
|
|
|
SBLaunchInfo::SBLaunchInfo(const SBLaunchInfo &rhs) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, rhs);
|
2020-01-29 08:44:30 +08:00
|
|
|
|
|
|
|
m_opaque_sp = rhs.m_opaque_sp;
|
|
|
|
}
|
|
|
|
|
2020-01-29 09:09:49 +08:00
|
|
|
SBLaunchInfo &SBLaunchInfo::operator=(const SBLaunchInfo &rhs) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, rhs);
|
2020-01-29 08:44:30 +08:00
|
|
|
|
|
|
|
m_opaque_sp = rhs.m_opaque_sp;
|
2022-01-10 14:54:08 +08:00
|
|
|
return *this;
|
2020-01-29 08:44:30 +08:00
|
|
|
}
|
|
|
|
|
2020-02-18 14:57:06 +08:00
|
|
|
SBLaunchInfo::~SBLaunchInfo() = default;
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2015-02-13 22:31:06 +08:00
|
|
|
const lldb_private::ProcessLaunchInfo &SBLaunchInfo::ref() const {
|
|
|
|
return *m_opaque_sp;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
void SBLaunchInfo::set_ref(const ProcessLaunchInfo &info) {
|
|
|
|
*m_opaque_sp = info;
|
|
|
|
}
|
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
lldb::pid_t SBLaunchInfo::GetProcessID() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
return m_opaque_sp->GetProcessID();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBLaunchInfo::GetUserID() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
return m_opaque_sp->GetUserID();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBLaunchInfo::GetGroupID() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
return m_opaque_sp->GetGroupID();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::UserIDIsValid() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
return m_opaque_sp->UserIDIsValid();
|
|
|
|
}
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
bool SBLaunchInfo::GroupIDIsValid() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
return m_opaque_sp->GroupIDIsValid();
|
|
|
|
}
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
void SBLaunchInfo::SetUserID(uint32_t uid) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, uid);
|
2015-02-05 07:19:15 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
m_opaque_sp->SetUserID(uid);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
void SBLaunchInfo::SetGroupID(uint32_t gid) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, gid);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
m_opaque_sp->SetGroupID(gid);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
SBFileSpec SBLaunchInfo::GetExecutableFile() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2022-01-10 14:54:08 +08:00
|
|
|
return SBFileSpec(m_opaque_sp->GetExecutableFile());
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetExecutableFile(SBFileSpec exe_file,
|
|
|
|
bool add_as_first_arg) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, exe_file, add_as_first_arg);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->SetExecutableFile(exe_file.ref(), add_as_first_arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
SBListener SBLaunchInfo::GetListener() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2022-01-10 14:54:08 +08:00
|
|
|
return SBListener(m_opaque_sp->GetListener());
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetListener(SBListener &listener) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, listener);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->SetListener(listener.GetSP());
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBLaunchInfo::GetNumArguments() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetArguments().GetArgumentCount();
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetArgumentAtIndex(uint32_t idx) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, idx);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetArguments().GetArgumentAtIndex(idx);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetArguments(const char **argv, bool append) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, argv, append);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
if (append) {
|
|
|
|
if (argv)
|
|
|
|
m_opaque_sp->GetArguments().AppendArguments(argv);
|
|
|
|
} else {
|
|
|
|
if (argv)
|
|
|
|
m_opaque_sp->GetArguments().SetArguments(argv);
|
2016-09-07 04:57:50 +08:00
|
|
|
else
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->GetArguments().Clear();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBLaunchInfo::GetNumEnvironmentEntries() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
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
|
|
|
return m_opaque_sp->GetEnvironment().size();
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetEnvironmentEntryAtIndex(uint32_t idx) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, idx);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
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
|
|
|
if (idx > GetNumEnvironmentEntries())
|
|
|
|
return nullptr;
|
|
|
|
return m_opaque_sp->GetEnvp()[idx];
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetEnvironmentEntries(const char **envp, bool append) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, envp, append);
|
2020-03-21 10:31:33 +08:00
|
|
|
SetEnvironment(SBEnvironment(Environment(envp)), append);
|
|
|
|
}
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2020-03-21 10:31:33 +08:00
|
|
|
void SBLaunchInfo::SetEnvironment(const SBEnvironment &env, bool append) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, env, append);
|
2020-03-21 10:31:33 +08:00
|
|
|
Environment &refEnv = env.ref();
|
2020-07-06 22:44:37 +08:00
|
|
|
if (append) {
|
|
|
|
for (auto &KV : refEnv)
|
|
|
|
m_opaque_sp->GetEnvironment().insert_or_assign(KV.first(), KV.second);
|
|
|
|
} else
|
2020-03-21 10:31:33 +08:00
|
|
|
m_opaque_sp->GetEnvironment() = refEnv;
|
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
|
|
|
m_opaque_sp->RegenerateEnvp();
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
2020-03-21 10:31:33 +08:00
|
|
|
SBEnvironment SBLaunchInfo::GetEnvironment() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2022-01-10 14:54:08 +08:00
|
|
|
return SBEnvironment(Environment(m_opaque_sp->GetEnvironment()));
|
2020-03-21 10:31:33 +08:00
|
|
|
}
|
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
void SBLaunchInfo::Clear() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
m_opaque_sp->Clear();
|
|
|
|
}
|
2015-02-05 07:19:15 +08:00
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetWorkingDirectory() const {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-05-30 03:52:29 +08:00
|
|
|
return m_opaque_sp->GetWorkingDirectory().GetCString();
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetWorkingDirectory(const char *working_dir) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, working_dir);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
m_opaque_sp->SetWorkingDirectory(FileSpec(working_dir));
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBLaunchInfo::GetLaunchFlags() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetFlags().Get();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetLaunchFlags(uint32_t flags) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, flags);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->GetFlags().Reset(flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetProcessPluginName() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetProcessPluginName();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetProcessPluginName(const char *plugin_name) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, plugin_name);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->SetProcessPluginName(plugin_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetShell() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Constify this string so that it is saved in the string pool. Otherwise it
|
|
|
|
// would be freed when this function goes out of scope.
|
2015-02-05 07:19:15 +08:00
|
|
|
ConstString shell(m_opaque_sp->GetShell().GetPath().c_str());
|
|
|
|
return shell.AsCString();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetShell(const char *path) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, path);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
m_opaque_sp->SetShell(FileSpec(path));
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
2015-02-21 06:20:30 +08:00
|
|
|
bool SBLaunchInfo::GetShellExpandArguments() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-21 06:20:30 +08:00
|
|
|
return m_opaque_sp->GetShellExpandArguments();
|
2015-02-10 11:16:55 +08:00
|
|
|
}
|
|
|
|
|
2015-02-21 06:20:30 +08:00
|
|
|
void SBLaunchInfo::SetShellExpandArguments(bool expand) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, expand);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-21 06:20:30 +08:00
|
|
|
m_opaque_sp->SetShellExpandArguments(expand);
|
2015-02-10 11:16:55 +08:00
|
|
|
}
|
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
uint32_t SBLaunchInfo::GetResumeCount() {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetResumeCount();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetResumeCount(uint32_t c) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, c);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->SetResumeCount(c);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::AddCloseFileAction(int fd) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fd);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->AppendCloseFileAction(fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::AddDuplicateFileAction(int fd, int dup_fd) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fd, dup_fd);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->AppendDuplicateFileAction(fd, dup_fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::AddOpenFileAction(int fd, const char *path, bool read,
|
|
|
|
bool write) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fd, path, read, write);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
return m_opaque_sp->AppendOpenFileAction(fd, FileSpec(path), read, write);
|
2015-02-05 07:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::AddSuppressFileAction(int fd, bool read, bool write) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fd, read, write);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->AppendSuppressFileAction(fd, read, write);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetLaunchEventData(const char *data) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, data);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->SetLaunchEventData(data);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBLaunchInfo::GetLaunchEventData() const {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetLaunchEventData();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetDetachOnError(bool enable) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, enable);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
m_opaque_sp->SetDetachOnError(enable);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBLaunchInfo::GetDetachOnError() const {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2015-02-05 07:19:15 +08:00
|
|
|
return m_opaque_sp->GetDetachOnError();
|
|
|
|
}
|
2019-03-20 01:13:13 +08:00
|
|
|
|
2021-03-24 00:22:07 +08:00
|
|
|
const char *SBLaunchInfo::GetScriptedProcessClassName() const {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2021-03-24 00:22:07 +08:00
|
|
|
|
|
|
|
// Constify this string so that it is saved in the string pool. Otherwise it
|
|
|
|
// would be freed when this function goes out of scope.
|
|
|
|
ConstString class_name(m_opaque_sp->GetScriptedProcessClassName().c_str());
|
|
|
|
return class_name.AsCString();
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetScriptedProcessClassName(const char *class_name) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, class_name);
|
2021-03-24 00:22:07 +08:00
|
|
|
|
|
|
|
m_opaque_sp->SetScriptedProcessClassName(class_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBStructuredData SBLaunchInfo::GetScriptedProcessDictionary() const {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2021-03-24 00:22:07 +08:00
|
|
|
|
|
|
|
lldb_private::StructuredData::DictionarySP dict_sp =
|
|
|
|
m_opaque_sp->GetScriptedProcessDictionarySP();
|
|
|
|
|
|
|
|
SBStructuredData data;
|
|
|
|
data.m_impl_up->SetObjectSP(dict_sp);
|
|
|
|
|
2022-01-10 14:54:08 +08:00
|
|
|
return data;
|
2021-03-24 00:22:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBLaunchInfo::SetScriptedProcessDictionary(lldb::SBStructuredData dict) {
|
2022-01-20 03:38:26 +08:00
|
|
|
LLDB_INSTRUMENT_VA(this, dict);
|
2021-11-11 00:43:19 +08:00
|
|
|
if (!dict.IsValid() || !dict.m_impl_up)
|
|
|
|
return;
|
2021-03-24 00:22:07 +08:00
|
|
|
|
2021-11-11 00:43:19 +08:00
|
|
|
StructuredData::ObjectSP obj_sp = dict.m_impl_up->GetObjectSP();
|
2021-03-24 00:22:07 +08:00
|
|
|
|
2021-11-11 00:43:19 +08:00
|
|
|
if (!obj_sp)
|
2021-03-24 00:22:07 +08:00
|
|
|
return;
|
|
|
|
|
2021-11-11 00:43:19 +08:00
|
|
|
StructuredData::DictionarySP dict_sp =
|
|
|
|
std::make_shared<StructuredData::Dictionary>(obj_sp);
|
|
|
|
if (!dict_sp || dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
|
|
|
|
return;
|
2021-03-24 00:22:07 +08:00
|
|
|
|
|
|
|
m_opaque_sp->SetScriptedProcessDictionarySP(dict_sp);
|
|
|
|
}
|