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
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
Due to internal reuse of buffers in the RenderScript runtime by the system allocator,
comparing pointers is not a safe way to check whether an allocation is tracked by lldb.
This change updates the lldb RenderScript internal hook callback to properly
identify and remove old allocations that had have an address that is currently
being tracked.
This change also removes the need for `lldb_private::renderscript::LookupAllocation`
to take a `create` flag, as this is now always the case.
Original Author: <dean@codeplay.com>
Subscribers: lldb-commits
llvm-svn: 277613
``num_params`` was unused in RenderScript ABI fixup pass ``cloneToStructRetFnTy``
and was only used in an `assert()` that the number of function parameters for the cloned
function was correct.
Now we actually use this variable, rather than recomputing it, and avoid the unused variable
warning when building without asserts enabled.
Subscribers: lldb-commits
llvm-svn: 277608
Expression evaluation for function calls to certain public RenderScript
API functions in libRSCPURef can segfault.
`slang`,
the compiler frontend for RenderScript embeds an ARM specific triple in
IR that is shipped in the app, after generating IR that has some
assumptions that an ARM device is the target.
As the IR is then compiled on a device of unknown (at time the IR was
generated at least) architecture, when calling RenderScript API function
as part of debugger expressions, we have to perform a fixup pass that
removes those assumptions right before the module is sent to be
generated by the llvm backend.
This issue is caused by multiple problems with the ARMv7-specific
assumptions encoded in the LLVM IR. x86 large value returns use a hidden
first argument (mapping to llvm::Attribute::StructRet), which can't be
picked up by the JIT due to the mismatch between IR generated by the
slang frontend and llvm backend. This means that code generated by bcc
did not necessarily match the default SysV Linux/Android ABI used by the
LLDB JIT
- Original Authors: Luke Drummond (@ldrumm), Function declarations fixed by Aidan Dodds (@ADodds)
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D18059
llvm-svn: 276976
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
some (I'm not sure why only some, actually) implementations of std::map require the value type to
be a fully specified type when declaring then. This make sure TypeAndOrName is.
llvm-svn: 270570
One of the things slowing us down is that ItaniumABILanguageRuntime class doesn't cache vtable to types in a map. This causes us, on every step, for every variable, to read the first pointer in a C++ type that could be dynamic and lookup the symbol, possibly in every symbol file (some symbols files on Darwin can end up having thousands of .o files when using DWARF in .o files, so thousands of .o files are searched each time).
This fix caches lldb_private::Address (the resolved vtable symbol address in section + offset format) to TypeAndOrName instances inside the one ItaniumABILanguageRuntime in a process. This allows caching of dynamic types and stops us from always doing deep searches in each file.
<rdar://problem/18890778>
llvm-svn: 270488
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
"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
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
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
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
Fix a problem raised with the previous patches being applied in the wrong order.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263134
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263131
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263130
Currently it is not specified, and since allocations are usually
requested once we hit a renderscript breakpoint, the language will be
inferred being as renderscript by the ExpressionParser.
Actually allocations attempt to invoke functions part of the RS runtime,
written in C/C++, so evaluating the calls in RenderScript could be
misleading.
In particular, in MIPS, the ABI between C/C++ (mips o32) and
renderscript (arm) might introduce subtle bugs when evaluating such
expressions.
This change explicitly sets the language used to evaluate the allocations
as C++.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263129
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
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
Mips64 tests were failing on windows because the sscanf implementation differs between clang/gcc/msvc such that on windows %lx specifies a 32bits parameter and %llx is for 64bits. For us this meant that 64bit pointers were being truncated to 32bits on their way into a JIT'd expression.
llvm-svn: 261741
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
This patch reworks the function argument reading code, allowing us to annotate arguments with their types. The type/size information is needed to correctly parse arguments passed on the stack.
llvm-svn: 260525
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries.
This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files.
<rdar://problem/24581488>
llvm-svn: 260434
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes
Fixes rdar://24460882
llvm-svn: 259964
Patch replaces the --refresh flag removed in r258800 with it's own command, 'language renderscript allocation refresh'.
Since there is no reason this functionality should be tied to another command as an option.
The command itself simply re-JITs all our cached information about allocations.
llvm-svn: 259773
Patch deletes the 'language renderscript module probe' command.
This command was present in the initial commit to help debug the plugin.
However we haven't used it recently and it's functionality is unclear, so can be removed entirely.
Also add back 'kernel coordinate' command, removed by accident in clang format patch r259056.
llvm-svn: 259181
Patch replaces the 'renderscript allocation list' command flag --refresh, with a new option --id <ID>.
This new option only prints the details of a single allocation with a given id, rather than printing all the allocations.
Functionality from the removed '--refresh' flag will be moved into its own command in a subsequent commit.
llvm-svn: 258800
std::array should have "the same semantics as a struct holding a C-style array T[N] as its only
non-static data member", so the initialization should have one more level of braces. Hopefully,
no compiler will object to that.
llvm-svn: 258306
Patch adds command 'language renderscript kernel coordinate' for printing the kernel index in (x,y,z) format.
This is done by walking the call stack and looking for a function with suffix '.expand', as well as the frame variables containing the coordinate data.
llvm-svn: 258303
Reverts earlier commit r254910, which used function pointers for jitted expressions
to avoid a Mips64 compiler bug. Bug has since been fixed, and compiler longer issues the problem instruction.
Author: Dean De Leo <dean@codeplay.com>
llvm-svn: 258038
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
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
Updates the file format for storing RS allocations to a file, so that the format now supports struct element types.
The file header will now contain a subheader for every RS element and it's descendants.
Where an element subheader contains element type details and offsets to the subheaders of that elements fields.
Patch also improves robustness when loading incorrect files.
llvm-svn: 257045
Function arguments that were spilled and passed on the stack were incorrectly read.
The value was written back into the output pointer rather then the memory being pointed to.
llvm-svn: 256941
Reverts "Use correct format identifiers to print something meaningful."
Original format specifiers were correct.
Instead use void* casts to remove warnings, since this is what the %p specifier expects.
llvm-svn: 256833
Currently we can just inspect the details of the most common allocation types.
This patch allows us to support all the types defined by the RS runtime in its `RsDataType` enum.
Including handlers, matrices and packed graphical data.
llvm-svn: 255904
Adds support for reading a maximum of six integer arguments from a renderscript hook on X86_64.
Author: Luke Drummond <luke.drummond@codeplay.com>
llvm-svn: 255338
Patch creates a member function that decides when to JIT all the details about an allocation.
By checking for zero pointers we can avoid the situation where we store uninitialised data from previously inspecting the allocation during creation.
llvm-svn: 255238
New hook for rsdAllocationDestroy() which is called when allocations are deleted.
LLDB should be aware of this so we can remove the allocation from our internal list.
llvm-svn: 255121
Workaround for Mips64 compiler bug by using function pointers to call
functions for expression evaluation. This avoids the emission of the JAL instruction,
which can only jump within a particular range of the PC.
Author: Dean De Leo, dean@codeplay.com
llvm-svn: 254910
This patch adds functionality for dumping allocations of struct elements. This involves:
+ Jitting the runtime for details on all the struct fields.
+ Finding the name of the struct type by looking for a global variable of the same type, which will have been reflected back to the java host code.
+ Using this struct type name to pass into expression evaluation for pretty printing the data for the dump command.
llvm-svn: 254294
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
Adds option -c <x,y,z> to the 'language renderscript kernel breakpoint set' command.
Breaks only on the invocation of the kernel with specified coordinate.
Implemented by adding a callback to the kernel breakpoint which checks the coordinates of every invocation.
llvm-svn: 251293
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
Previously we could not hook the RS runtime on mips64 architectures.
Patch implements ABI specific code for inspecting function arguments.
Author: Dean De Leo, dean@codeplay.com
llvm-svn: 251003
Patch adds command 'language renderscript allocation save' to store the contents of an allocation in a binary file.
And 'language renderscript allocation load' to restore an allocation with the saved data from a binary file.
Binary file format contains a header FileHeader with meta information preceding the raw data.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, domipheus
Differential Revision: http://reviews.llvm.org/D13903
llvm-svn: 250886
Previous commit r250281 broke TestDataFormatterSmartArray.py
Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager.
Differential Revision: http://reviews.llvm.org/D13730
llvm-svn: 250499
This patch adds the command 'language renderscript allocation dump <ID>' for printing the contents of a RS allocation.
Displaying the coordinate of each element as well as its formatted value
e.g (lldb) language renderscript allocation dump 1
Data (X, Y, Z):
(0, 0, 0) = {0 1}
(1, 0, 0) = {2 3}
(2, 0, 0) = {4 5}
A --file <filename> option is also included, since for large allocations it may be more helpful to view this text as a file.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, brucem
Differential Revision: http://reviews.llvm.org/D13699
llvm-svn: 250281
This patch adds a new command 'language renderscript allocation list' for printing the details of all loaded RS allocations.
In order to work out this information lldb JITs the runtime for the data it wants.
This has a penalty of a couple seconds latency, so is only done once for each allocation and the results cached.
If the user later wants to recalculate this information however, they can force lldb to do so with the --refresh flag.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, dean, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D13247
llvm-svn: 249380
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
Ed Maste