Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability. The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.
Differential Revision: https://reviews.llvm.org/D59427
llvm-svn: 356481
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
The current record macros already log the function being called. This
patch extends the macros to also log their input arguments and removes
explicit logging from the SB API.
This might degrade the amount of information in some cases (because of
smarter casts or efforts to log return values). However I think this is
outweighed by the increased coverage and consistency. Furthermore, using
the reproducer infrastructure, diagnosing bugs in the API layer should
become much easier compared to relying on log messages.
Differential revision: https://reviews.llvm.org/D59101
llvm-svn: 355649
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().
So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.
This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.
Differential revision: https://reviews.llvm.org/D58946
llvm-svn: 355458
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the ResolveExecutableLocation method from FileSpec
and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53834
llvm-svn: 345853
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
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
*** 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
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
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
Michal Gorny
Pavel Labath
Jonas Devlieghere
Chandler Carruth
Zachary Turner
Pavel Labath
Kate Stone
Jason Molenda
Chaoren Lin
Ilia K
Bruce Mitchener
Sean Callanan