If a breakpoint was hit in the inferior after shutdown had
started but before it was complete, it would cause an unclean
terminate of the inferior, leading to various problems the most
visible of which is that handles to the inferior executable would
remain locked, and the test suite would fail to run subsequent
tests because it could not recompile the inferior.
This fixes a major source of flakiness in the test suite.
llvm-svn: 247929
Character with ASCII code 0 is incorrectly treated by LLDB as the end of
RSP packet. The left of the debugger server output is silently ignored.
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12523
llvm-svn: 247908
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
The implications of this bug where that "log disable windows" would
not actually disable the log, and worse it would lock the file handle
making it impossible to delete the file until lldb was shut down.
This was then causing the test suite to fail, because the test suite
tries to delete log files in certain situations.
llvm-svn: 247841
Summary: Supports the parsing of the "using namespace XXX" and "using XXX::XXX" directives. Added ambiguity errors when it two decls with the same name are encountered (see comments in TestCppNsImport). Fixes using directives being duplicated for anonymous namespaces. Fixes GetDeclForUID for specification DIEs.
Reviewers: sivachandra, chaoren, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12897
llvm-svn: 247836
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.
Differential revision: http://reviews.llvm.org/D12880
llvm-svn: 247789
Use Breakpoint::AddName to mark all RenderScript kernel breakpoints with the name 'RenderScriptKernel'.
Also update logging channels to include LIBLLDB_LOG_BREAKPOINT where appropriate.
llvm-svn: 247782
SUMMARY:
Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion
on this topic. Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC,
qfThreadInfo, Hg and Hc packets. Reply from ? packet is as simple as S05. There is no
packet which gives us process or threads information. In such cases, assume pid=tid=1.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D12876
llvm-svn: 247773
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
SUMMARY:
This patch provides support for MIPS specific DT_MIPS_RLD_MAP_REL tag in LLDB.
This tag allows debugging of MIPS position independent executables and provides access to shared library information.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D12794
llvm-svn: 247666
Summary:
Linux and FreeBSD occasionally send SI_KERNEL codes, nonexistent on other platforms.
Problem caught on NetBSD.
Reviewers: joerg, sas
Subscribers: sas, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D12659
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 247579
The iterator pointing to an element of a dense map was used after
the element from was removed from the map what isn't guaranteed to be
valid at that time.
llvm-svn: 247571
RegisterContextPOSIX.h is poorly named and contains only the declaration
of POSIXBreakpointProtocol, which is used for in-process live kernel
debugging. It is now relevant only to FreeBSD.
In source/Plugins/Process/Utility/RegisterContext*.h (after assorted
rework and refactoring) it only served the purpose of #including other
necessary headers as a side-effect. Remove it from them and just include
the required headers directly.
Differential Revision: http://reviews.llvm.org/D12830
llvm-svn: 247558
Summary:
Realtime signals generally do not represent an error condition in an application but are more
like a regular means of IPC. As such, we shouldn't interrupt an application whenever it recieves
one. If any application will use these signals, it will probably use them a lot, rendering it's
debugging tiresome if we stopped at every signal. Furthermore, these signals are likely to be used
in a low level library, and the programmer may not even be aware of their presence.
For these reasons, I am switching the default disposition of realtime signals on all supported
platforms (i.e. Linux and Freebsd) to no-stop, no-notify. Any user still wishing to receive these
signals can always change the default to suit his needs.
Reviewers: ovyalov, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D12795
llvm-svn: 247537
Summary:
This builds on all platforms, so remove duplication in build
configuration.
Reviewers: labath, clayborg, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12792
llvm-svn: 247402
Change the mapping symbol handling to handle the case when the mapping
symbols are prefixed with an arbitrary prefix. This isn't strictly standard
compliance, but if all symbols in an object file is prefixed with objcopy
then the prefix will be added to the mapping symbol also. We still want to
treat these symbols as mapping symbols to get the correct address class data.
Differential revision: http://reviews.llvm.org/D12755
llvm-svn: 247400
Summary:
* cmake/LLDBDependencies.cmake: elf-core is already included
globally in LLDB_USED_LIBS, so it doesn't need to be re-added
on individual platforms.
* lib/Makefile: elf-core is linked on each platform, so move it
to the global list of used libraries.
* source/Plugins/Makefile: elf-core is built on each platform, so
move it to the global list of things to build.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12762
llvm-svn: 247366
Summary:
We currently link to this on all platforms, so don't need to re-include
it into the LLDB_USED_LIBS. Also don't need to special case building
it for every supported platform.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12756
llvm-svn: 247284
Patch adds a command to RenderScript plugin allowing users to automatically set breakpoints on every RS kernel.
Command syntax is 'language renderscript kernel breakpoint all <enable/disable>.'
Enable sets breakpoints on all currently loaded kernels, and any kernels which will be loaded in future.
Disable results in breakpoints no longer being set on loaded kernels, but doesn't affect existing breakpoints.
Current command 'language renderscript kernel breakpoint' is changed to 'language renderscript kernel breakpoint set'
Reviewed by: clayborg, jingham
Subscribers: lldb-commits, ADodds, domipheus
Differential Revision: http://reviews.llvm.org/D12728
llvm-svn: 247262
In some special case (e.g. signal handlers, hand written assembly) it is
valid to have 2 stack frame with the same CFA value. This CL change the
looping stack detection code to report a loop only if at least 3
consecutive frames have the same CFA.
Differential revision: http://reviews.llvm.org/D12699
llvm-svn: 247133
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable
Differential revision: http://reviews.llvm.org/D12291
llvm-svn: 247132
* Remove some unused code
* Remove usage of DWARFDebugInfoEntry::Attributes where usage isn't
reasonable
* Cleanup DWARFMappedHash with separating it to header and implementation
file and fixing the visibility of the functions
Differential revision: http://reviews.llvm.org/D12374
llvm-svn: 247131
qXfer:features:read:target.xml packet, or via the
plugin.process.gdb-remote.target-definition-file setting, if the
register definition doesn't give us eh_frame or DWARF register
numbers for that register, try to get that information from the ABI
plugin.
The DWARF/eh_frame register numbers are defined in the ABI
standardization documents - so getting this from the ABI plugin is
reasonable. There's little value in having the remote stub inform
us of this generic information, as long as we can all agree on the
names of the registers.
There's some additional information we could get from the ABI. For
instance, on ABIs where function arguments are passed in registers,
lldb defines alternate names like "arg1", "arg2", "arg3" for these
registers so they can be referred to that way by the user. We could
get this from the ABI if the remote stub doesn't provide that. That
may be something worth doing in the future - but for now, I'm keeping
this a little more minimal.
Thinking about this, what we want/need from the remote stub at a
minimum are:
1. The names of the register
2. The number that the stub will use to refer to the register with
the p/P packets and in the ? response packets (T/S) where
expedited register values are provided
3. The size of the register in bytes
(nice to have, to remove any doubt)
4. The offset of the register in the g/G packet if we're going to
use that for reading/writing registers.
debugserver traditionally provides a lot more information in
addition to this via the qRegisterInfo packet, and debugserver
augments its response to the qXfer:features:read:target.xml
query to include this information. Including:
DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754,
Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*,
float), registers that should be marked as invalid if this
register is modified, and registers that contain this register.
We might want to get all of this from the ABI - I'm not convinced
that it makes sense for the remote stub to provide any of these
details, as long as the ABI and remote stub can agree on register
names.
Anyway, start with eh_frame and DWARF coming from the ABI if
they're not provided by the remote stub. We can look at doing
more in the future.
<rdar://problem/22566585>
llvm-svn: 247121
When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-hex encoding so we don't
dump random 8-bit characters into the packet log.
I'm changing this check to allow whitespace characters
(newlines, linefeeds, tabs) to be printed if those are
the only non-printable characters in the packet.
This is primarily to get the response to the
qXfer:features:read:target.xml packet to show up in the
packet logs in human readable form. Right now we just
get a dozen kilobytes of hex-ascii and it's hard to
figure out what register number scheme is being used.
llvm-svn: 247120
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
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible
methods, I've done the same for ExpressionVariable. The main documentation for
how to do this is in TypeSystem.h, so I've simply referred to that.
llvm-svn: 247085
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like:
class TypeSystem
{
virtual ClangASTContext *
AsClangASTContext() = 0;
}
As you can now just use the llvm::dyn_cast and other casts.
llvm-svn: 247041
Summary:
- For 'register read --all' command on x86_64-Linux Platform:
-- Provide correct values of X87 FPU Special Purpose Registers
-- Both 32-bit & 64-bit inferiors give correct values on this
Platform
- Added a Test Vector:
-- To verify the expected behaviour of the command
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ashok.thirumurthi, granata.enrico, tfiala, clayborg
Differential Revision: http://reviews.llvm.org/D12592
llvm-svn: 246955
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
Currently the RS breakpoint command can only find a kernel if it's in an already loaded RS module.
This patch allows users to set pending breakpoints on RenderScript kernels which will be loaded in the future.
Implemented by creating a RS breakpoint resolver, to limit search scope to only RS modules.
Reviewed by: clayborg, jingham
Subscribers: lldb-commits, ADodds, domipheus
Differential Revision: http://reviews.llvm.org/D12360
llvm-svn: 246842
Summary:
- Capability to force return user specified values
from inside of a function on lldb command terminal
- Support for Integral, Pointer and Floating Point values
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, clayborg
Subscribers: tberghammer
Differential Revision: http://reviews.llvm.org/D12595
llvm-svn: 246841
ehframe_ & from gdb_ to stabs_ for clarity.
Also document the fact that i386 eh_frame on Darwin has the register
numbers swapped for ebp/esp from the DWARF register numbers so no one
copies these defines for other i386 ABI plugins. This bug only ever
existed on Darwin.
No code changes, just renaming variables.
llvm-svn: 246834
Summary:
The AppleGetQueuesHandler code no longer needs to include a header
from the AppleObjCRuntime, so we can remove workarounds that were
present in the build systems.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12589
llvm-svn: 246821
Summary:
There was a race condition in the AsyncThread, where we would end up sending a vAttach
notification to the thread before it got a chance set up its listener (this can be reproduced by
adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then
get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the
ProcessGDBRemote constructor.
This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from
TestAttachResume, and will watch the buildbots for signs of trouble.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12552
llvm-svn: 246756
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
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
This fixes a regression caused by r245645 where creating alternative
thumb disassembler was enabled even when the main disassembler is
already thumb.
llvm-svn: 246649
If no architecture is defined for the disassambler command then it uses
the architecture of the target. In case of arm it will be "arm" what is
treated as the oldest arm version by the LLVM disassambler causing a lot
of invalid opcode in the output.
This change forces the use of "armv8.1a" (the newest arm architecture) if
no sub architecure was specified (either by the user or by the target) to
disassamble all instruction.
Differential revision: http://reviews.llvm.org/D12553
llvm-svn: 246648
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
Summary:
This was removed from the other ABI plugins long ago. This removes
a warning that was happening in this unused code as a result of
adding 2 new types to Scalar.h (e_uint128 and e_sint128).
Reviewers: clayborg
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12514
llvm-svn: 246608
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
When detaching, we need to detach from all threads of the inferior and not just the main one.
Without this, a multi-threaded inferior would usually crash once the server exits.
llvm-svn: 246549
Linux sometimes sends us a PTRACE_EVENT_EXIT when an inferior process gets a SIGKILL. This can be
confusing, since normally we don't expect any events when the inferior is stopped. This commit
adds code to handle this situation (resume the thread and let it exit normally) and avoid an
assertion failure in ResumeThread().
llvm-svn: 246539
class DWARFASTParser
{
public:
virtual ~DWARFASTParser() {}
virtual lldb::TypeSP
ParseTypeFromDWARF (const lldb_private::SymbolContext& sc,
const DWARFDIE &die,
lldb_private::Log *log,
bool *type_is_new_ptr) = 0;
virtual lldb_private::Function *
ParseFunctionFromDWARF (const lldb_private::SymbolContext& sc,
const DWARFDIE &die) = 0;
virtual bool
CompleteTypeFromDWARF (const DWARFDIE &die,
lldb_private::Type *type,
lldb_private::CompilerType &clang_type) = 0;
virtual lldb_private::CompilerDeclContext
GetDeclContextForUIDFromDWARF (const DWARFDIE &die) = 0;
virtual lldb_private::CompilerDeclContext
GetDeclContextContainingUIDFromDWARF (const DWARFDIE &die) = 0;
};
We have one subclass named DWARFASTParserClang that implements all of the clang specific AST type parsing. This keeps all DWARF parsing in the DWARF plug-in. Moved all of the DWARF parsing code that was in ClangASTContext over into DWARFASTParserClang.
lldb_private::TypeSystem classes no longer have any DWARF parsing functions in them, but they can hand out a DWARFASTParser:
virtual DWARFASTParser *
GetDWARFParser ()
{
return nullptr;
}
This keeps things clean and makes for easy merging when we have different AST's for different languages.
llvm-svn: 246242
Adrian McCarthy