| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
empty objective C types from the runtime.
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
|
|
|
|
| |
llvm-svn: 288797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
|
|
|
|
| |
llvm-svn: 286723
|
|
|
|
|
|
| |
none of this is super-critical since it applies to older versions of macOS (or OSX, I guess?) but still..
llvm-svn: 285599
|
|
|
|
| |
llvm-svn: 282741
|
|
|
|
|
|
|
| |
It doesn't like the implicit conversion from T[] to ArrayRef<T>
so I'm using `llvm::makeArrayRef()`. Hopefully I got everything.
llvm-svn: 282195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
|
|
|
|
|
|
|
|
|
|
| |
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
|
|
|
|
|
|
|
|
| |
data() pointers, effectively rendering us unable to generate descriptors for some classes
Fixes rdar://27758358
llvm-svn: 281282
|
|
|
|
|
|
|
|
| |
The switch coveres all possible values. If a new one is added in the
future the compiler will start warning, providing a notification that
the switch needs updating.
llvm-svn: 280933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
| |
Patch by Taras Tsugrii
llvm-svn: 280283
|
|
|
|
|
|
|
|
| |
two singleton (pairtons?) instances of __NSCFBoolean that represent true and false
This is useful because that knowledge will in turn allow no-code-running formatting of boolean NSNumbers; but that's a commit that will have to wait Monday..
llvm-svn: 279353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.
This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.
Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham
llvm-svn: 278440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
|
|
|
|
|
|
| |
legitimately possible for a process to define no ObjC classes of its own. Discovered by debugging /bin/ls
llvm-svn: 277897
|
|
|
|
|
|
| |
to grab logs when such issues occur, make the logs more helpful, and also tweaks to the user messaging to make it easier to pinpoint an investigation avenue early on
llvm-svn: 277844
|
|
|
|
|
|
|
|
|
|
| |
legitimate albeit suboptimal - and warn about being unable to fetch ObjC class information, even though class data was actually properly loaded from the dynamic hashmap
Only ever warn about missing ObjC runtime class data if one either can't run the expressions to obtain such data, or the total count of classes is below a threshold that makes things sound really suspicious
Fixes rdar://27438500
llvm-svn: 276220
|
|
|
|
|
|
|
|
|
| |
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The function FunctionCaller::WriteFunctionArguments returns false on
errors, so they should check for the false return value.
Change by Walter Erquinigo <a20012251@gmail.com>
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22278
llvm-svn: 275287
|
|
|
|
|
|
|
|
|
| |
It belongs in the instance, since then when you change architectures it can be adjusted
appropriately.
<rdar://problem/26308079>
llvm-svn: 270938
|
|
|
|
| |
llvm-svn: 270024
|
|
|
|
|
|
|
|
|
|
| |
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
|
|
|
|
|
|
| |
<rdar://problem/26207478>
llvm-svn: 269378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Allow LanguageRuntimes to return an error if they fail in the course of dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors"
I need to think about what I want to do in this space more carefully - this attempt might be too heavy of a hammer for the nail I am trying to fix, and I don't want to leave it in while I ponder
llvm-svn: 268686
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors
llvm-svn: 268591
|
|
|
|
|
|
|
|
| |
not to log depending on whether the types log is enabled
This can prove helpful in debugging issues with that retrieval even if LLDB wasn't compiled with the magic macros defined
llvm-svn: 268587
|
|
|
|
| |
llvm-svn: 268303
|
|
|
|
| |
llvm-svn: 266401
|
|
|
|
| |
llvm-svn: 266274
|
|
|
|
| |
llvm-svn: 266271
|
|
|
|
|
|
| |
which makes it print ivar and method information, as well as an optional regex argument which filters out all class names that don't match the regex
llvm-svn: 266267
|
|
|
|
|
|
| |
rdar://problem/24401051
llvm-svn: 266001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in question are CanCompleteType,
CompleteType, and CanImport. Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.
A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.
Differential Revision: http://reviews.llvm.org/D18381
llvm-svn: 264685
|
|
|
|
|
|
|
|
|
|
| |
functions) so I added
a way for compilation to take a "thread to use for compilation". If it isn't set then the
compilation will use the currently selected thread. This should help keep function execution
to the one thread intended.
llvm-svn: 263972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.
I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.
<rdar://problem/24978569>
llvm-svn: 263326
|
|
|
|
|
|
|
|
|
|
|
|
| |
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
|
|
|
|
|
|
|
|
|
|
|
| |
class information from
This code was doing the right thing for the iOS simulator, but not other simulator platforms
Fix it by making the warning not happen for all platforms whose name ends in "-simulator"
Since this code lives in AppleObjCRuntimeV2.cpp, this already only applies to Apple platforms by definition, so I am not too worried about conflicts with other vendors
llvm-svn: 261165
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D16662
llvm-svn: 259098
|
|
|
|
|
|
|
| |
assuming a ValueObject always has a process. So this is that fix
and the test case.
llvm-svn: 257242
|
|
|
|
|
|
|
|
|
|
|
|
| |
that the
process in the incoming value be non-null, but Value Objects created off the target
don't necessarily have a process. In that case, having the targets the same is good
enough.
<rdar://problem/24097805>
llvm-svn: 257234
|
|
|
|
| |
llvm-svn: 253732
|
|
|
|
| |
llvm-svn: 252272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a resubmission of r252179, but correctly ignores the source
files for other platforms.
Reviewers: granata.enrico, tberghammer, zturner, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14389
llvm-svn: 252205
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13968
llvm-svn: 251031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This short-circuits the GetObjCVersion function to avoid iterating through target modules on
non-apple targets. This function is called on every Process::IsDynamicValue call, so this
overhead is not negligible.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13948
llvm-svn: 251004
|
|
|
|
|
|
|
|
| |
source/Plugins/LanguageRuntime; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13966
llvm-svn: 250966
|
|
|
|
|
|
|
|
|
| |
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
|