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
RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.
In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.
First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true. This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.
Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.
Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC. This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.
However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken. If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.
Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:
// Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp),
// and our "current" pc is the start of a function...
if (m_sym_ctx_valid
&& GetNextFrame()->m_frame_type != eTrapHandlerFrame
&& GetNextFrame()->m_frame_type != eDebuggerFrame
&& addr_range.GetBaseAddress().IsValid()
&& addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
&& addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
{
decr_pc_and_recompute_addr_range = true;
}
In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function. But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.
In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.
A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function. In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.
A related problem is that the ResolveSymbolContextForAddress sometimes
returns a "symbol" with empty name. This turns out to be an ELF section
symbol. Now, usually those get type eSymbolTypeInvalid. However, there
is code in ObjectFileELF::ParseSymbols that tries to change the type of
invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol
lies within the code or data section.
Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode. While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.
Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.
The fix for this problem is me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.
Differential Revision: http://reviews.llvm.org/D18975
llvm-svn: 267363
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA. This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.
However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes. This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes. This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.
In order to make this work on s390x, this patch introduces a new
ABI callback GetFallbackRegisterLocation that provides platform-
specific fallback register locations for unwinding. The existing
code to handle SP unwinding as well as volatile registers is moved
into the default implementation of that ABI callback, to allow
targets where that implementation is incorrect to override it.
This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.
Differential Revision: http://reviews.llvm.org/D18977
llvm-svn: 266307
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
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.
Differential revision: http://reviews.llvm.org/D17604
llvm-svn: 262014
reason to None when we stop due to a trace, then noticed that
we were on a breakpoint that was not valid for the current thread.
That should actually have set it back to trace.
This was pr26441 (<rdar://problem/24470203>)
llvm-svn: 259684
register set indicated by ARM_THREAD_STATE32 (value 9) instead of
the old ARM_THREAD_STATE (value 1); this patch changes lldb to
accept either register set flavor code.
<rdar://problem/24246257>
llvm-svn: 258289
Summary:
The testcase TestNoreturnUnwind.py was failing
because the unwind from the vdso library was not
successful for clang compiler while it was passing
for gcc. It was passing for gcc since the unwind plan
used was the assembly plan and the ebp register was
set by the main function in case of gcc and was not
used by the functions in the call flow to the vdso, whereas
clang did not emit assembly prologue for main and so
the assembly unwind was failing. Normally in case of
failure of assembly unwind, lldb switches to EH CFI frame
based unwinding, but this was not happening for
the first frame. This patch tries to fix this behaviour by
falling to EH CFI frame based unwinding in case of assembly
unwind failure even for the first frame.
The test is still marked as XFAIL since it relys on the fix
of another bug.
Reviewers: lldb-commits, jingham, zturner, tberghammer, jasonmolenda
Subscribers: jasonmolenda
Differential Revision: http://reviews.llvm.org/D15046
llvm-svn: 257465
Summary:
When we construct AppleObjCTrampolineHandler, if m_impl_fn_addr is
invalid, we call CanJIT(). If the gdb remote process does not support
allocating and deallocating memory, this call stack will include a call
to the AppleObjCRuntime constructor. The AppleObjCRuntime constructor
will then call the AppleObjCTrampolineHandler constructor, creating a
recursive call loop that eventually overflows the stack and segfaults.
Avoid this call loop by not constructing the AppleObjCTrampolineHandler
within AppleObjCRuntime until we actually need to use it.
Reviewers: clayborg, jingham
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D15978
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257204
Summary:
- Reason of both bugs:
1. For the very first frame, Unwinder doesn't check the validity
of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.
2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
fails and FallBack UnwindPlan succeeds in providing valid CFA values
for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, lldb-commits, jasonmolenda
Subscribers: lldb-commits, ovyalov, tberghammer
Differential Revision: http://reviews.llvm.org/D14226
llvm-svn: 253026
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
set to true, but all plans run by RunThreadPlan need to have this set to false so they will
return control to RunThreadPlan without consulting plans higher on the stack.
Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior.
<rdar://problem/22543166>
llvm-svn: 250084
Summary:
- Changed from 16 bits to 8 bits for Intel Architecture
-- FXSAVE structure now conforms with the layout of FXSAVE
area specified by IA Architecture Software Developer Manual
- Modified Linux and FreeBSD specific files to support this change
-- MacOSX already uses 8 bits for ftag register
- Modified TestRegisters.py and a.cpp:
-- Change allows 8 bit comparison of ftag values
-- Change resolves Bug 24733:
Removed XFAIL for Clang as the test works and passes for
Clang compiler as well
-- Change provides a Generic/Better way of testing Bug 24457
and Bug 25050 by using 'int3' inline assembly in inferior
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, clayborg
Subscribers: tfiala, emaste
Differential Revision: http://reviews.llvm.org/D13587
llvm-svn: 250022
* Use .ARM.exidx as a fallback unwind plan for non-call site when the
instruction emulation based unwind failed.
* Work around an old compiler issue where the compiler isn't sort the
entries in .ARM.exidx based on their address.
* Fix unwind info parsing when the virtual file address >= 0x80000000
* Fix bug in unwind info parsing when neither lr nor pc is explicitly
restored.
Differential revision: http://reviews.llvm.org/D13380
llvm-svn: 249119
.ARM.exidx/.ARM.extab sections contain unwind information used on ARM
architecture from unwinding from an exception.
Differential revision: http://reviews.llvm.org/D13245
llvm-svn: 248903
"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
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
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
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
This was breaking disassembly for arm machines that we force to be
thumb mode all the time because we were only checking for llvm::Triple::arm.
i.e.
armv6m (ARM Cortex-M0)
armv7m (ARM Cortex-M3)
armv7em (ARM Cortex-M4)
<rdar://problem/22334522>
llvm-svn: 245645
This patch :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste
Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential: http://reviews.llvm.org/D10919
llvm-svn: 245217
numbers in the key name "ehframe" or "eh_frame" in addition to the deprecated
"gcc" name (e.g. from a plugin.process.gdb-remote.target-definition-file
python file).
llvm-svn: 245151
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:
For Linux x86 based environments the orig_eax/orig_rax
register should be set to -1 to prevent the instruction pointer
to be decremented, which was the cause for the SIGILL exception.
Fix for Bug 23659
Reviewers: zturner, ashok.thirumurthi, mikesart, jingham, clayborg
Subscribers: clayborg, labath
Differential Revision: http://reviews.llvm.org/D11411
llvm-svn: 244875
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This change :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
- Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types.
Reviewers : emaste, jaydeep, clayborg
Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential : http://reviews.llvm.org/D10919
llvm-svn: 244308
This one I accidentally missed last time because I confused it with
the lldbUtility library. After this, all makefile libraries should
have the same names as their CMake counterparts.
llvm-svn: 242344
Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.
Reviewers: ovyalov, clayborg
Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11094
llvm-svn: 242101
Previously we accepted a frame as correct result if the PC pointed
into an executable section of code. The isse with that approac is
that if we calculated PC correctly but messed up the value of CFA
then unwinding from the next fram will most likely fail.
With this change I modify the logic with keeping the requirement
for PC to point to an executable section and also check that we can
continue the unwind from the frame we calculated. If continuing from
the frame calculated with the primary unwind plan isn't working then
fall back to the fallback plan with the hope for a better frame (if
the fallback plan won't help then we acceot the frame from the
primary plan).
Differential revision: http://reviews.llvm.org/D10932
llvm-svn: 241434
Previously if the instruction emulation based unwind plan failed then
we fall back to the arch default unwind plan. Change it to fall back
to the eh_frame based one even on non call sites if we have eh_frame
as that one tend to be more reliable.
Differential revision: http://reviews.llvm.org/D10902
llvm-svn: 241334