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
