llvm-project/lldb/source/API/SBLaunchInfo.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

413 lines
11 KiB
C++
Raw Normal View History

//===-- SBLaunchInfo.cpp --------------------------------------------------===//
//
// 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
//
//===----------------------------------------------------------------------===//
#include "lldb/API/SBLaunchInfo.h"
#include "lldb/Utility/Instrumentation.h"
2020-03-20 19:31:33 -07:00
#include "lldb/API/SBEnvironment.h"
#include "lldb/API/SBError.h"
#include "lldb/API/SBFileSpec.h"
#include "lldb/API/SBListener.h"
#include "lldb/API/SBStream.h"
#include "lldb/API/SBStructuredData.h"
#include "lldb/Core/StructuredDataImpl.h"
#include "lldb/Host/ProcessLaunchInfo.h"
#include "lldb/Utility/Listener.h"
#include "lldb/Utility/ScriptedMetadata.h"
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 11:57:31 +00:00
class lldb_private::SBLaunchInfoImpl : public ProcessLaunchInfo {
public:
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 11:57:31 +00: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;
};
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 11:57:31 +00:00
: m_opaque_sp(new SBLaunchInfoImpl()) {
LLDB_INSTRUMENT_VA(this, argv);
m_opaque_sp->GetFlags().Reset(eLaunchFlagDebug | eLaunchFlagDisableASLR);
if (argv && argv[0])
m_opaque_sp->GetArguments().SetArguments(argv);
}
SBLaunchInfo::SBLaunchInfo(const SBLaunchInfo &rhs) {
LLDB_INSTRUMENT_VA(this, rhs);
m_opaque_sp = rhs.m_opaque_sp;
}
SBLaunchInfo &SBLaunchInfo::operator=(const SBLaunchInfo &rhs) {
LLDB_INSTRUMENT_VA(this, rhs);
m_opaque_sp = rhs.m_opaque_sp;
2022-01-09 22:54:08 -08:00
return *this;
}
SBLaunchInfo::~SBLaunchInfo() = default;
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 11:57:31 +00:00
void SBLaunchInfo::set_ref(const ProcessLaunchInfo &info) {
*m_opaque_sp = info;
}
lldb::pid_t SBLaunchInfo::GetProcessID() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetProcessID();
}
uint32_t SBLaunchInfo::GetUserID() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetUserID();
}
uint32_t SBLaunchInfo::GetGroupID() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetGroupID();
}
bool SBLaunchInfo::UserIDIsValid() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->UserIDIsValid();
}
bool SBLaunchInfo::GroupIDIsValid() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GroupIDIsValid();
}
void SBLaunchInfo::SetUserID(uint32_t uid) {
LLDB_INSTRUMENT_VA(this, uid);
m_opaque_sp->SetUserID(uid);
}
void SBLaunchInfo::SetGroupID(uint32_t gid) {
LLDB_INSTRUMENT_VA(this, gid);
m_opaque_sp->SetGroupID(gid);
}
SBFileSpec SBLaunchInfo::GetExecutableFile() {
LLDB_INSTRUMENT_VA(this);
2022-01-09 22:54:08 -08:00
return SBFileSpec(m_opaque_sp->GetExecutableFile());
}
void SBLaunchInfo::SetExecutableFile(SBFileSpec exe_file,
bool add_as_first_arg) {
LLDB_INSTRUMENT_VA(this, exe_file, add_as_first_arg);
m_opaque_sp->SetExecutableFile(exe_file.ref(), add_as_first_arg);
}
SBListener SBLaunchInfo::GetListener() {
LLDB_INSTRUMENT_VA(this);
2022-01-09 22:54:08 -08:00
return SBListener(m_opaque_sp->GetListener());
}
void SBLaunchInfo::SetListener(SBListener &listener) {
LLDB_INSTRUMENT_VA(this, listener);
m_opaque_sp->SetListener(listener.GetSP());
}
uint32_t SBLaunchInfo::GetNumArguments() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetArguments().GetArgumentCount();
}
const char *SBLaunchInfo::GetArgumentAtIndex(uint32_t idx) {
LLDB_INSTRUMENT_VA(this, idx);
return ConstString(m_opaque_sp->GetArguments().GetArgumentAtIndex(idx))
.GetCString();
}
void SBLaunchInfo::SetArguments(const char **argv, bool append) {
LLDB_INSTRUMENT_VA(this, argv, append);
if (append) {
if (argv)
m_opaque_sp->GetArguments().AppendArguments(argv);
} else {
if (argv)
m_opaque_sp->GetArguments().SetArguments(argv);
else
m_opaque_sp->GetArguments().Clear();
}
}
uint32_t SBLaunchInfo::GetNumEnvironmentEntries() {
LLDB_INSTRUMENT_VA(this);
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 11:57:31 +00:00
return m_opaque_sp->GetEnvironment().size();
}
const char *SBLaunchInfo::GetEnvironmentEntryAtIndex(uint32_t idx) {
LLDB_INSTRUMENT_VA(this, idx);
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 11:57:31 +00:00
if (idx > GetNumEnvironmentEntries())
return nullptr;
return ConstString(m_opaque_sp->GetEnvp()[idx]).GetCString();
}
void SBLaunchInfo::SetEnvironmentEntries(const char **envp, bool append) {
LLDB_INSTRUMENT_VA(this, envp, append);
2020-03-20 19:31:33 -07:00
SetEnvironment(SBEnvironment(Environment(envp)), append);
}
2020-03-20 19:31:33 -07:00
void SBLaunchInfo::SetEnvironment(const SBEnvironment &env, bool append) {
LLDB_INSTRUMENT_VA(this, env, append);
2020-03-20 19:31:33 -07:00
Environment &refEnv = env.ref();
if (append) {
for (auto &KV : refEnv)
m_opaque_sp->GetEnvironment().insert_or_assign(KV.first(), KV.second);
} else
2020-03-20 19:31:33 -07: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 11:57:31 +00:00
m_opaque_sp->RegenerateEnvp();
}
2020-03-20 19:31:33 -07:00
SBEnvironment SBLaunchInfo::GetEnvironment() {
LLDB_INSTRUMENT_VA(this);
2022-01-09 22:54:08 -08:00
return SBEnvironment(Environment(m_opaque_sp->GetEnvironment()));
2020-03-20 19:31:33 -07:00
}
void SBLaunchInfo::Clear() {
LLDB_INSTRUMENT_VA(this);
m_opaque_sp->Clear();
}
const char *SBLaunchInfo::GetWorkingDirectory() const {
LLDB_INSTRUMENT_VA(this);
[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-25 23:29:30 -07:00
return m_opaque_sp->GetWorkingDirectory().GetPathAsConstString().AsCString();
}
void SBLaunchInfo::SetWorkingDirectory(const char *working_dir) {
LLDB_INSTRUMENT_VA(this, working_dir);
m_opaque_sp->SetWorkingDirectory(FileSpec(working_dir));
}
uint32_t SBLaunchInfo::GetLaunchFlags() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetFlags().Get();
}
void SBLaunchInfo::SetLaunchFlags(uint32_t flags) {
LLDB_INSTRUMENT_VA(this, flags);
m_opaque_sp->GetFlags().Reset(flags);
}
const char *SBLaunchInfo::GetProcessPluginName() {
LLDB_INSTRUMENT_VA(this);
return ConstString(m_opaque_sp->GetProcessPluginName()).GetCString();
}
void SBLaunchInfo::SetProcessPluginName(const char *plugin_name) {
LLDB_INSTRUMENT_VA(this, plugin_name);
return m_opaque_sp->SetProcessPluginName(plugin_name);
}
const char *SBLaunchInfo::GetShell() {
LLDB_INSTRUMENT_VA(this);
// 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 shell(m_opaque_sp->GetShell().GetPath().c_str());
return shell.AsCString();
}
void SBLaunchInfo::SetShell(const char *path) {
LLDB_INSTRUMENT_VA(this, path);
m_opaque_sp->SetShell(FileSpec(path));
}
bool SBLaunchInfo::GetShellExpandArguments() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetShellExpandArguments();
}
void SBLaunchInfo::SetShellExpandArguments(bool expand) {
LLDB_INSTRUMENT_VA(this, expand);
m_opaque_sp->SetShellExpandArguments(expand);
}
uint32_t SBLaunchInfo::GetResumeCount() {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetResumeCount();
}
void SBLaunchInfo::SetResumeCount(uint32_t c) {
LLDB_INSTRUMENT_VA(this, c);
m_opaque_sp->SetResumeCount(c);
}
bool SBLaunchInfo::AddCloseFileAction(int fd) {
LLDB_INSTRUMENT_VA(this, fd);
return m_opaque_sp->AppendCloseFileAction(fd);
}
bool SBLaunchInfo::AddDuplicateFileAction(int fd, int dup_fd) {
LLDB_INSTRUMENT_VA(this, fd, dup_fd);
return m_opaque_sp->AppendDuplicateFileAction(fd, dup_fd);
}
bool SBLaunchInfo::AddOpenFileAction(int fd, const char *path, bool read,
bool write) {
LLDB_INSTRUMENT_VA(this, fd, path, read, write);
return m_opaque_sp->AppendOpenFileAction(fd, FileSpec(path), read, write);
}
bool SBLaunchInfo::AddSuppressFileAction(int fd, bool read, bool write) {
LLDB_INSTRUMENT_VA(this, fd, read, write);
return m_opaque_sp->AppendSuppressFileAction(fd, read, write);
}
void SBLaunchInfo::SetLaunchEventData(const char *data) {
LLDB_INSTRUMENT_VA(this, data);
m_opaque_sp->SetLaunchEventData(data);
}
const char *SBLaunchInfo::GetLaunchEventData() const {
LLDB_INSTRUMENT_VA(this);
return ConstString(m_opaque_sp->GetLaunchEventData()).GetCString();
}
void SBLaunchInfo::SetDetachOnError(bool enable) {
LLDB_INSTRUMENT_VA(this, enable);
m_opaque_sp->SetDetachOnError(enable);
}
bool SBLaunchInfo::GetDetachOnError() const {
LLDB_INSTRUMENT_VA(this);
return m_opaque_sp->GetDetachOnError();
}
const char *SBLaunchInfo::GetScriptedProcessClassName() const {
LLDB_INSTRUMENT_VA(this);
ScriptedMetadataSP metadata_sp = m_opaque_sp->GetScriptedMetadata();
if (!metadata_sp || !*metadata_sp)
return nullptr;
// 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(metadata_sp->GetClassName().data());
return class_name.AsCString();
}
void SBLaunchInfo::SetScriptedProcessClassName(const char *class_name) {
LLDB_INSTRUMENT_VA(this, class_name);
ScriptedMetadataSP metadata_sp = m_opaque_sp->GetScriptedMetadata();
StructuredData::DictionarySP dict_sp =
metadata_sp ? metadata_sp->GetArgsSP() : nullptr;
metadata_sp = std::make_shared<ScriptedMetadata>(class_name, dict_sp);
m_opaque_sp->SetScriptedMetadata(metadata_sp);
}
lldb::SBStructuredData SBLaunchInfo::GetScriptedProcessDictionary() const {
LLDB_INSTRUMENT_VA(this);
ScriptedMetadataSP metadata_sp = m_opaque_sp->GetScriptedMetadata();
SBStructuredData data;
if (!metadata_sp)
return data;
lldb_private::StructuredData::DictionarySP dict_sp = metadata_sp->GetArgsSP();
data.m_impl_up->SetObjectSP(dict_sp);
2022-01-09 22:54:08 -08:00
return data;
}
void SBLaunchInfo::SetScriptedProcessDictionary(lldb::SBStructuredData dict) {
LLDB_INSTRUMENT_VA(this, dict);
if (!dict.IsValid() || !dict.m_impl_up)
return;
StructuredData::ObjectSP obj_sp = dict.m_impl_up->GetObjectSP();
if (!obj_sp)
return;
StructuredData::DictionarySP dict_sp =
std::make_shared<StructuredData::Dictionary>(obj_sp);
if (!dict_sp || dict_sp->GetType() == lldb::eStructuredDataTypeInvalid)
return;
ScriptedMetadataSP metadata_sp = m_opaque_sp->GetScriptedMetadata();
llvm::StringRef class_name = metadata_sp ? metadata_sp->GetClassName() : "";
metadata_sp = std::make_shared<ScriptedMetadata>(class_name, dict_sp);
m_opaque_sp->SetScriptedMetadata(metadata_sp);
}
SBListener SBLaunchInfo::GetShadowListener() {
LLDB_INSTRUMENT_VA(this);
lldb::ListenerSP shadow_sp = m_opaque_sp->GetShadowListener();
if (!shadow_sp)
return SBListener();
return SBListener(shadow_sp);
}
void SBLaunchInfo::SetShadowListener(SBListener &listener) {
LLDB_INSTRUMENT_VA(this, listener);
ListenerSP listener_sp = listener.GetSP();
if (listener_sp && listener.IsValid())
listener_sp->SetShadow(true);
else
listener_sp = nullptr;
m_opaque_sp->SetShadowListener(listener_sp);
}