This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go
So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables
llvm-svn: 247112
It is required because of the following edge case on arm:
bx <addr> Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol
The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.
Differential revision: http://reviews.llvm.org/D12556
llvm-svn: 246958
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
* Change Module::MatchesModuleSpec to return true in case the file spec
in the specified module spec matches with the platform file spec, but
not with the local file spec
* Change the module_resolver used when resolving a remote shared module
to always set the platform file spec to the file spec requested
Differential revision: http://reviews.llvm.org/D12601
llvm-svn: 246852
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
There was a race condition in Process class, where we would not wait for process stdout to
propagate fully before we would shut down the connection (repro case: slow down the stdio thread
by placing a sleep right at the end of the while loop in Communication::ReadThread). The Process
class already tried to solve this problem by synchronizing with the read thread in
Process::ShouldBroadcastEvent, but unfortunately the connection got closed before that in
Process::SetExitStatus. I solve this issue by delaying the connection shutdown until we get a
chance to process the event and synchronize. Alternatively, I could have moved the
synchronization point to an earlier point in SetExitStatus, but it seems safer to delay the
shutdown until other things get a chance to notice the process has exited.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12558
llvm-svn: 246753
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246568
Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)
This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin
The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters
No formatters are moved as part of this change, so practically speaking this is NFC
llvm-svn: 246515
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin
The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation
At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++
llvm-svn: 246212
This will do things like,
given mylibrary,
return
libmylibrary.dylib on OSX
mylibrary.dll on Windows
and so on for other platforms
It is currently implemented for Windows, Darwin, and Linux. Other platforms should fill in accordingly
llvm-svn: 246131
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
SUMMARY:
This patch implements Target::GetBreakableLoadAddress() method that takes an address
and checks for any reason there is a better address than this to put a breakpoint on.
If there is then return that address.
MIPS uses this method to avoid breakpoint in delay slot.
Reviewers: clayborg, jingham
Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits
Differential Revision: http://http://reviews.llvm.org/D12184
llvm-svn: 246015
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
SUMMARY:
Last 3bits of the watchpoint address are masked by the kernel. For example, n is
at 0x120010d00 and m is 0x120010d04. When a watchpoint is set at m, then watch
exception is generated even when n is read/written. To handle this case, instruction
at PC is emulated to find the base address of the load/store instruction. This address
is then appended to the description of the stop-info packet. Client then reads this
information to check whether the user has set a watchpoint on this address.
Reviewers: jingham, clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D11672
llvm-svn: 244864
On android .oat files (compiled java code) don't have symbol
information but on SDK 23+ it can be generated by the oatdump tool
(based on the dex information).
This CL adds logic to download this information and store it in the
module cache.
Differential revision: http://reviews.llvm.org/D11936
llvm-svn: 244738
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
contained within Process so that we won't be duplicating the warning
message if other parts of the code want to issue the message. Change
Process::PrintWarning to be a protected method - the public method
will be the PrintWarningOptimization et al. Also, Have
Thread::FunctionOptimizationWarning shortcut out if the warnings
have been disabled so that we don't (potentially) compute parts of
the SymbolContext unnecessarily.
llvm-svn: 244436
per Module instead of once per CompileUnit, and print the
module name. A module may have a mix of compile units built with
optimization and compile units built without optimization -- the
warning won't be printed until the user selects a stack frame of
a function that was built with optimization. And as before, it
will only be printed once per module per debug session.
<rdar://problem/19281172>
llvm-svn: 244281
The first part was in r243508 -- the extent of the UI changes in that
patchset was to add "[opt]" to the frame-format when a stack frame was
built with optimized code.
In this change, when a stack frame built with optimization is selected,
a message will be printed to the async output channel --
opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available.
The warning will be only be printed once per source file in a debug session.
These warnings may be disabled by
settings set target.process.optimization-warnings false
Internally, a new Process::PrintWarning() method has been added for
warnings that we want to print only once to the user. It takes a type
of warning (currently only eWarningsOptimization) and an object
pointer (CompileUnit*) - the warning will only be printed once for a
given object pointer value.
This is a bit of a prototype of this change - I think we will be
tweaking it more in the future. But I wanted to land this and see
how it goes. Advanced users will find these warnings unnecessary
noise and will quickly disable them - but anyone who maintains a
debugger knows that debugging optimized code, without realizing it,
is a constant source of confusion and frustation for more typical
debugger users.
I imagine there will be more of these "warn once per whatever" style
warnings that we will want to add in the future and we'll need to
come up with a better way for enabling/disabling them. But I'm not
srue what form that warning settings should take and I didn't want
to code up something that we regret later, so for now I just added
another process setting for this one warning.
<rdar://problem/19281172>
llvm-svn: 244190
owners list, so the StopInfo machinery can get the list of owners without
some other thread being able to mess up the list by deleting/disabline one of its
locations in the process of doing so.
<rdar://problem/18685197>
llvm-svn: 243541
dSYMs, or reading binaries out of memory to the 'Host' log channel.
There's more to be done here, both for Mac and for other platforms,
but the initial set of new loggings are useful enough to check in
at this point.
llvm-svn: 243200
If the function is a template then the return type is part of the
function name. This CL fixes the parsing of these function names in
the case when the return type contains ':'.
The name of free functions in C++ don't have context part. Fix the
logic geting the function name without arguments out from a full
function name to handle this case.
Change the handling of step-in-avoid-regexp to match the value against
the function name without it's arguments and return value. This is
required because the default regex ("^std::") would match any template
function returning an std object.
Fifferential revision: http://reviews.llvm.org/D11461
llvm-svn: 243099
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
but that wasn't added to the list of reasons they don't explain. That
would mean we keep stepping after hitting the AsanDie breakpoint rather
than stopping when the Asan event occurred.
<rdar://problem/21925479>
llvm-svn: 243035
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread.
Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops.
llvm-svn: 242593
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
