[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
|
|
|
//===-- SBFileSpec.cpp ----------------------------------------------------===//
|
2010-06-09 00:52:24 +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
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/API/SBFileSpec.h"
|
2019-03-06 08:06:00 +08:00
|
|
|
#include "SBReproducerPrivate.h"
|
|
|
|
#include "Utils.h"
|
2010-09-20 13:20:02 +08:00
|
|
|
#include "lldb/API/SBStream.h"
|
2018-11-02 01:09:22 +08:00
|
|
|
#include "lldb/Host/FileSystem.h"
|
2017-03-23 01:33:23 +08:00
|
|
|
#include "lldb/Host/PosixApi.h"
|
2017-03-23 02:40:07 +08:00
|
|
|
#include "lldb/Utility/FileSpec.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/Stream.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2014-08-08 01:33:36 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
|
|
|
|
2021-05-26 18:19:37 +08:00
|
|
|
#include <cinttypes>
|
|
|
|
#include <climits>
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
SBFileSpec::SBFileSpec() : m_opaque_up(new lldb_private::FileSpec()) {
|
|
|
|
LLDB_RECORD_CONSTRUCTOR_NO_ARGS(SBFileSpec);
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2019-03-06 08:05:55 +08:00
|
|
|
SBFileSpec::SBFileSpec(const SBFileSpec &rhs) : m_opaque_up() {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_CONSTRUCTOR(SBFileSpec, (const lldb::SBFileSpec &), rhs);
|
|
|
|
|
2019-03-06 08:05:55 +08:00
|
|
|
m_opaque_up = clone(rhs.m_opaque_up);
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
2013-07-09 06:22:41 +08:00
|
|
|
SBFileSpec::SBFileSpec(const lldb_private::FileSpec &fspec)
|
2019-02-13 14:25:41 +08:00
|
|
|
: m_opaque_up(new lldb_private::FileSpec(fspec)) {}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2014-07-02 05:22:11 +08:00
|
|
|
// Deprecated!!!
|
2019-02-13 14:25:41 +08:00
|
|
|
SBFileSpec::SBFileSpec(const char *path) : m_opaque_up(new FileSpec(path)) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_CONSTRUCTOR(SBFileSpec, (const char *), path);
|
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
FileSystem::Instance().Resolve(*m_opaque_up);
|
2018-11-02 05:05:36 +08:00
|
|
|
}
|
2010-10-21 04:54:39 +08:00
|
|
|
|
|
|
|
SBFileSpec::SBFileSpec(const char *path, bool resolve)
|
2019-02-13 14:25:41 +08:00
|
|
|
: m_opaque_up(new FileSpec(path)) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_CONSTRUCTOR(SBFileSpec, (const char *, bool), path, resolve);
|
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
if (resolve)
|
2019-02-13 14:25:41 +08:00
|
|
|
FileSystem::Instance().Resolve(*m_opaque_up);
|
2018-11-02 05:05:36 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2020-02-18 14:57:06 +08:00
|
|
|
SBFileSpec::~SBFileSpec() = default;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
const SBFileSpec &SBFileSpec::operator=(const SBFileSpec &rhs) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD(const lldb::SBFileSpec &,
|
|
|
|
SBFileSpec, operator=,(const lldb::SBFileSpec &), rhs);
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (this != &rhs)
|
2019-03-06 08:05:55 +08:00
|
|
|
m_opaque_up = clone(rhs.m_opaque_up);
|
2019-04-04 05:31:22 +08:00
|
|
|
return LLDB_RECORD_RESULT(*this);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
Make operator==s consistent between c++ and python APIs
Summary:
modify-python-lldb.py had code to insert python equality operators to
some classes. Some of those classes already had c++ equality operators,
and some didn't.
This makes the situation more consistent, by removing all equality
handilng from modify-python-lldb. Instead, I add c++ operators to
classes where they were missing, and expose them in the swig interface
files so that they are available to python too.
The only tricky case was the SBAddress class, which had an operator==
defined as a free function, which is not handled by swig. This function
cannot be removed without breaking ABI, and we cannot add an extra
operator== member, as that would make equality comparisons ambiguous.
For this class, I define a python __eq__ function by hand and have it
delegate to the operator!=, which I have defined as a member function.
This isn't fully NFC, as the semantics of some equality functions in
python changes slightly, but I believe it changes for the better (e.g.,
previously SBBreakpoint.__eq__ would consider two breakpoints with the
same ID as equal, even if they belonged to different targets; now they
are only equal if they belong to the same target).
Reviewers: jingham, clayborg, zturner
Subscribers: jdoerfert, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D59819
llvm-svn: 357463
2019-04-02 18:18:46 +08:00
|
|
|
bool SBFileSpec::operator==(const SBFileSpec &rhs) const {
|
|
|
|
LLDB_RECORD_METHOD_CONST(bool, SBFileSpec, operator==,(const SBFileSpec &rhs),
|
|
|
|
rhs);
|
|
|
|
|
|
|
|
return ref() == rhs.ref();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBFileSpec::operator!=(const SBFileSpec &rhs) const {
|
|
|
|
LLDB_RECORD_METHOD_CONST(bool, SBFileSpec, operator!=,(const SBFileSpec &rhs),
|
|
|
|
rhs);
|
|
|
|
|
|
|
|
return !(*this == rhs);
|
|
|
|
}
|
|
|
|
|
2019-03-06 08:06:00 +08:00
|
|
|
bool SBFileSpec::IsValid() const {
|
|
|
|
LLDB_RECORD_METHOD_CONST_NO_ARGS(bool, SBFileSpec, IsValid);
|
Add "operator bool" to SB APIs
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
2019-03-11 21:58:46 +08:00
|
|
|
return this->operator bool();
|
|
|
|
}
|
|
|
|
SBFileSpec::operator bool() const {
|
|
|
|
LLDB_RECORD_METHOD_CONST_NO_ARGS(bool, SBFileSpec, operator bool);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
|
|
|
return m_opaque_up->operator bool();
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
bool SBFileSpec::Exists() const {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD_CONST_NO_ARGS(bool, SBFileSpec, Exists);
|
|
|
|
|
2019-03-08 06:47:13 +08:00
|
|
|
return FileSystem::Instance().Exists(*m_opaque_up);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2010-09-10 12:48:55 +08:00
|
|
|
bool SBFileSpec::ResolveExecutableLocation() {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD_NO_ARGS(bool, SBFileSpec, ResolveExecutableLocation);
|
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
return FileSystem::Instance().ResolveExecutableLocation(*m_opaque_up);
|
2010-09-10 12:48:55 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
int SBFileSpec::ResolvePath(const char *src_path, char *dst_path,
|
|
|
|
size_t dst_len) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_STATIC_METHOD(int, SBFileSpec, ResolvePath,
|
|
|
|
(const char *, char *, size_t), src_path, dst_path,
|
|
|
|
dst_len);
|
|
|
|
|
2014-08-08 01:33:36 +08:00
|
|
|
llvm::SmallString<64> result(src_path);
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSystem::Instance().Resolve(result);
|
Fix FileSpec::GetPath to return null-terminated strings
Summary:
Before this fix the FileSpec::GetPath() returned string which might be without '\0' at the end.
It could have happened if the size of buffer for path was less than actual path.
Test case:
```
FileSpec test("/path/to/file", false);
char buf[]="!!!!!!";
test.GetPath(buf, 3);
```
Before fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/pa!!!"
```
After fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/p"
```
Reviewers: zturner, abidh, clayborg
Reviewed By: abidh, clayborg
Subscribers: tberghammer, vharron, lldb-commits, clayborg, zturner, abidh
Differential Revision: http://reviews.llvm.org/D7553
llvm-svn: 230787
2015-02-28 03:43:08 +08:00
|
|
|
::snprintf(dst_path, dst_len, "%s", result.c_str());
|
|
|
|
return std::min(dst_len - 1, result.size());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2010-08-28 06:35:26 +08:00
|
|
|
const char *SBFileSpec::GetFilename() const {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD_CONST_NO_ARGS(const char *, SBFileSpec, GetFilename);
|
|
|
|
|
2019-03-08 06:47:13 +08:00
|
|
|
return m_opaque_up->GetFilename().AsCString();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
const char *SBFileSpec::GetDirectory() const {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD_CONST_NO_ARGS(const char *, SBFileSpec, GetDirectory);
|
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
FileSpec directory{*m_opaque_up};
|
2015-06-09 06:12:58 +08:00
|
|
|
directory.GetFilename().Clear();
|
|
|
|
return directory.GetCString();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2013-11-21 05:07:01 +08:00
|
|
|
void SBFileSpec::SetFilename(const char *filename) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD(void, SBFileSpec, SetFilename, (const char *), filename);
|
|
|
|
|
2013-11-21 05:07:01 +08:00
|
|
|
if (filename && filename[0])
|
2019-02-13 14:25:41 +08:00
|
|
|
m_opaque_up->GetFilename().SetCString(filename);
|
2013-11-21 05:07:01 +08:00
|
|
|
else
|
2019-02-13 14:25:41 +08:00
|
|
|
m_opaque_up->GetFilename().Clear();
|
2013-11-21 05:07:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void SBFileSpec::SetDirectory(const char *directory) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD(void, SBFileSpec, SetDirectory, (const char *), directory);
|
|
|
|
|
2013-11-21 05:07:01 +08:00
|
|
|
if (directory && directory[0])
|
2019-02-13 14:25:41 +08:00
|
|
|
m_opaque_up->GetDirectory().SetCString(directory);
|
2013-11-21 05:07:01 +08:00
|
|
|
else
|
2019-02-13 14:25:41 +08:00
|
|
|
m_opaque_up->GetDirectory().Clear();
|
2013-11-21 05:07:01 +08:00
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
uint32_t SBFileSpec::GetPath(char *dst_path, size_t dst_len) const {
|
[lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.
During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.
This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.
To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.
Differential revision: https://reviews.llvm.org/D77759
2020-04-21 04:20:24 +08:00
|
|
|
LLDB_RECORD_CHAR_PTR_METHOD_CONST(uint32_t, SBFileSpec, GetPath,
|
|
|
|
(char *, size_t), dst_path, "", dst_len);
|
2019-03-06 08:06:00 +08:00
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
uint32_t result = m_opaque_up->GetPath(dst_path, dst_len);
|
2010-10-26 11:11:13 +08:00
|
|
|
|
2010-10-31 11:01:06 +08:00
|
|
|
if (result == 0 && dst_path && dst_len > 0)
|
2010-06-09 00:52:24 +08:00
|
|
|
*dst_path = '\0';
|
2010-10-31 11:01:06 +08:00
|
|
|
return result;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const lldb_private::FileSpec *SBFileSpec::operator->() const {
|
2019-02-13 14:25:41 +08:00
|
|
|
return m_opaque_up.get();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const lldb_private::FileSpec *SBFileSpec::get() const {
|
2019-02-13 14:25:41 +08:00
|
|
|
return m_opaque_up.get();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
const lldb_private::FileSpec &SBFileSpec::operator*() const {
|
2019-02-13 14:25:41 +08:00
|
|
|
return *m_opaque_up;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
const lldb_private::FileSpec &SBFileSpec::ref() const { return *m_opaque_up; }
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
void SBFileSpec::SetFileSpec(const lldb_private::FileSpec &fs) {
|
2019-02-13 14:25:41 +08:00
|
|
|
*m_opaque_up = fs;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2010-10-26 11:11:13 +08:00
|
|
|
bool SBFileSpec::GetDescription(SBStream &description) const {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD_CONST(bool, SBFileSpec, GetDescription, (lldb::SBStream &),
|
|
|
|
description);
|
|
|
|
|
2011-11-13 14:57:31 +08:00
|
|
|
Stream &strm = description.ref();
|
Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
2013-07-09 06:22:41 +08:00
|
|
|
char path[PATH_MAX];
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_opaque_up->GetPath(path, sizeof(path)))
|
Added a way to extract the module specifications from a file. A module specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
2013-07-09 06:22:41 +08:00
|
|
|
strm.PutCString(path);
|
2010-10-26 11:11:13 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-02-19 08:05:17 +08:00
|
|
|
|
|
|
|
void SBFileSpec::AppendPathComponent(const char *fn) {
|
2019-03-06 08:06:00 +08:00
|
|
|
LLDB_RECORD_METHOD(void, SBFileSpec, AppendPathComponent, (const char *), fn);
|
|
|
|
|
2019-02-13 14:25:41 +08:00
|
|
|
m_opaque_up->AppendPathComponent(fn);
|
2016-02-19 08:05:17 +08:00
|
|
|
}
|
2019-03-20 01:13:13 +08:00
|
|
|
|
|
|
|
namespace lldb_private {
|
|
|
|
namespace repro {
|
|
|
|
|
|
|
|
template <>
|
|
|
|
void RegisterMethods<SBFileSpec>(Registry &R) {
|
|
|
|
LLDB_REGISTER_CONSTRUCTOR(SBFileSpec, ());
|
|
|
|
LLDB_REGISTER_CONSTRUCTOR(SBFileSpec, (const lldb::SBFileSpec &));
|
|
|
|
LLDB_REGISTER_CONSTRUCTOR(SBFileSpec, (const char *));
|
|
|
|
LLDB_REGISTER_CONSTRUCTOR(SBFileSpec, (const char *, bool));
|
|
|
|
LLDB_REGISTER_METHOD(const lldb::SBFileSpec &,
|
|
|
|
SBFileSpec, operator=,(const lldb::SBFileSpec &));
|
Make operator==s consistent between c++ and python APIs
Summary:
modify-python-lldb.py had code to insert python equality operators to
some classes. Some of those classes already had c++ equality operators,
and some didn't.
This makes the situation more consistent, by removing all equality
handilng from modify-python-lldb. Instead, I add c++ operators to
classes where they were missing, and expose them in the swig interface
files so that they are available to python too.
The only tricky case was the SBAddress class, which had an operator==
defined as a free function, which is not handled by swig. This function
cannot be removed without breaking ABI, and we cannot add an extra
operator== member, as that would make equality comparisons ambiguous.
For this class, I define a python __eq__ function by hand and have it
delegate to the operator!=, which I have defined as a member function.
This isn't fully NFC, as the semantics of some equality functions in
python changes slightly, but I believe it changes for the better (e.g.,
previously SBBreakpoint.__eq__ would consider two breakpoints with the
same ID as equal, even if they belonged to different targets; now they
are only equal if they belong to the same target).
Reviewers: jingham, clayborg, zturner
Subscribers: jdoerfert, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D59819
llvm-svn: 357463
2019-04-02 18:18:46 +08:00
|
|
|
LLDB_REGISTER_METHOD_CONST(bool,
|
|
|
|
SBFileSpec, operator==,(const lldb::SBFileSpec &));
|
|
|
|
LLDB_REGISTER_METHOD_CONST(bool,
|
|
|
|
SBFileSpec, operator!=,(const lldb::SBFileSpec &));
|
2019-03-20 01:13:13 +08:00
|
|
|
LLDB_REGISTER_METHOD_CONST(bool, SBFileSpec, IsValid, ());
|
|
|
|
LLDB_REGISTER_METHOD_CONST(bool, SBFileSpec, operator bool, ());
|
|
|
|
LLDB_REGISTER_METHOD_CONST(bool, SBFileSpec, Exists, ());
|
|
|
|
LLDB_REGISTER_METHOD(bool, SBFileSpec, ResolveExecutableLocation, ());
|
|
|
|
LLDB_REGISTER_STATIC_METHOD(int, SBFileSpec, ResolvePath,
|
|
|
|
(const char *, char *, size_t));
|
|
|
|
LLDB_REGISTER_METHOD_CONST(const char *, SBFileSpec, GetFilename, ());
|
|
|
|
LLDB_REGISTER_METHOD_CONST(const char *, SBFileSpec, GetDirectory, ());
|
|
|
|
LLDB_REGISTER_METHOD(void, SBFileSpec, SetFilename, (const char *));
|
|
|
|
LLDB_REGISTER_METHOD(void, SBFileSpec, SetDirectory, (const char *));
|
|
|
|
LLDB_REGISTER_METHOD_CONST(bool, SBFileSpec, GetDescription,
|
|
|
|
(lldb::SBStream &));
|
|
|
|
LLDB_REGISTER_METHOD(void, SBFileSpec, AppendPathComponent, (const char *));
|
[lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.
During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.
This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.
To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.
Differential revision: https://reviews.llvm.org/D77759
2020-04-21 04:20:24 +08:00
|
|
|
LLDB_REGISTER_CHAR_PTR_METHOD_CONST(uint32_t, SBFileSpec, GetPath);
|
2019-03-20 01:13:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|