| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
It was a copy-and-paste leftover.
llvm-svn: 256248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"thread-pcs" key is added to the T (questionmark) packet in
gdb-remote protocol so that lldb doesn't need to query the
pc values of every thread before it resumes a process.
The only odd part with this is that I'm sending the pc
values in big endian order, so we need to know the endianness
of the remote process before we can use them. All other
register values in gdb-remote protocol are sent in native-endian
format so this requirement doesn't exist. This addition is a
performance enhancement -- lldb will fall back to querying the
pc of each thread individually if it needs to -- so when
we don't have the byte order for the process yet, we don't
use these values. Practically speaking, the only way I've
been able to elicit this condition is for the first
T packet when we attach to a process.
<rdar://problem/21963031>
llvm-svn: 255942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Signals 1-32 are matching the default UNIX platform.
There are platform specific ones above 32.
From the `/usr/include/sys/signal.h` header:
```
#define SIGPWR 32 /* power fail/restart (not reset when caught) */
#ifdef _KERNEL
#define SIGRTMIN 33 /* Kernel only; not exposed to userland yet */
#define SIGRTMAX 63 /* Kernel only; not exposed to userland yet */
#endif
```
Reviewers: emaste, joerg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15482
llvm-svn: 255592
|
|
|
|
| |
llvm-svn: 255419
|
|
|
|
|
|
|
|
| |
RegisterInfoInterface
This patch will fix the test case test_p_returns_correct_data_size_for_each_qRegisterInfo_attach_llgs_* of TestLldbGdbServer.py on mips. The test fails because we were sending RegisterInfo for msa registers to client even when msa registers are not available. With this commit server will send E45(end of resigters) response if msa registers are not available.
llvm-svn: 255108
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15359
llvm-svn: 255083
|
|
|
|
| |
llvm-svn: 255017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.
The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.
Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.
This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.
Differential revision: http://reviews.llvm.org/D14952
llvm-svn: 255016
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15218
llvm-svn: 254780
|
|
|
|
|
|
| |
available.
llvm-svn: 254743
|
|
|
|
|
|
|
|
|
| |
* Add support for representing signed integers
* Add new constructors taking any signed or unsigned integer types
Differential revision: http://reviews.llvm.org/D15187
llvm-svn: 254715
|
|
|
|
|
|
|
| |
SUMMARY:
Using enum instead of a constant to fetch PC and CAUSE registers.
llvm-svn: 254590
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.llvm.org/D15106
llvm-svn: 254522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Problem occurs when:
-- 32-bit inferiors run on x86_32 machine and
the architecture doesn't have AVX feature
-- This causes FPRType to be set to eFPRTypeFXSAVE
-- PTRACE_GETFPREGS was being used to read FXSAVE area
-- For 32-bit inferiors running on x86_32 machine,
PTRACE_GETFPREGS reads FSAVE area and not FXSAVE area
- Changed ptrace API to PTRACE_GETREGSET for 32-bit inferiors
-- This reads FPR data in FXSAVE format.
-- For 64-bit inferiors, no change has been made.
- Modified XFAIL for TestReturnValue.py
-- Earlier, this test was passing for Linux OS
-- Now, it passes for Android OS as well
Change-Id: Ieed72bc969b79516fc7b263b32493aa1e7a1a2ac
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, lldb-commits, tberghammer, labath
Subscribers: jevinskie, labath, tberghammer, danalbert
Differential Revision: http://reviews.llvm.org/D15042
llvm-svn: 254499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stepping on MIPS
This patch will clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS. The problem was that while emulating instructions, old and new pc values would have garbage value in their upper 32 bits. Therefore checking if pc was changed (old_pc == new_pc) would always return false, because of which pc was not getting updated.
/* If we haven't changed the PC, change it here */
if (old_pc == new_pc)
{
new_pc += 4;
Context context;
return false;
}
Reviewers: tberghammer, clayborg
Subscribers: dsanders, lldb-commits, mohit.bhakkad, bhushan, jaydeep, nitesh.jain
Differential: http://reviews.llvm.org/D14633
llvm-svn: 254379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the stop-reply packet). Normally, this should not happen
(the process cannot generate output when it is stopped), but due to the fact that pty
communication is asynchronous in the linux kernel (llvm.org/pr25652), we may sometimes get this
output too late. Instead, we just hold the output, and send it next time we resume. This is not
ideal, but at least it makes sure we do not violate the remote protocol. Given that this happens
extremely rarely it's not worth trying to work around it with sleeps or something like that.
I also remove the m_stdio_communication_mutex, as all of LLGS is now single-threaded anyway.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15019
llvm-svn: 254200
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14985
llvm-svn: 254152
|
|
|
|
|
|
|
|
| |
debug server connection failure.
http://reviews.llvm.org/D14895
llvm-svn: 253906
|
|
|
|
|
|
|
|
| |
Reviewers: jaydeep.
Subscribers: bhushan, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D14860
llvm-svn: 253864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14591
llvm-svn: 252950
|
|
|
|
|
|
|
|
|
|
| |
They get treated as special RLE encoding symbols and packets get
corrupted. Most other packet types already know about this apparently,
but QEnvironment missed these two.
Should fix PR25300.
llvm-svn: 252521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Same fix has been submitted for Arm.
Review can be found here:
Differential revision: http://reviews.llvm.org/D14051
llvm-svn: 252298
|
|
|
|
|
|
| |
Two minor tweaks to GetLoadedDynamicLibrariesInfos.
llvm-svn: 252242
|
|
|
|
|
|
| |
env packet if the '*' character used for run length encoding is present.
llvm-svn: 252239
|
|
|
|
|
|
|
|
|
|
| |
in places where we check for Triple::IOS. They're mostly the same as far
as lldb is conerned.
.
Also add a base cass implementation for Process::IsAlive - Greg added this
last year but it didn't get upstreamed.
llvm-svn: 252227
|
|
|
|
|
|
| |
can figure it out.
llvm-svn: 252224
|
|
|
|
|
|
| |
No build bots build x64 on Windows yet, but this was spotted by another developer who emailed me directly.
llvm-svn: 252100
|
|
|
|
| |
llvm-svn: 252094
|
|
|
|
|
|
|
|
| |
all packets that lldb-server or debugserver supports. The issue was the m_last_stop_packet_mutex mutex was being held by another thread and it was deadlocking getting the thread list. We now try to lock the m_last_stop_packet_mutex, and only continue if we successfully lock it. Else we fall back to qfThreadInfo/qsThreadInfo.
<rdar://problem/22140023>
llvm-svn: 252005
|
|
|
|
|
|
|
|
|
|
| |
physically present
Reviewers: clayborg, labath.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D13859
llvm-svn: 251906
|
|
|
|
|
|
| |
source/Plugins/Process/Utility headers; other minor fixes.
llvm-svn: 251676
|
|
|
|
|
|
|
|
| |
use the CPU type and subtype to fill out an architecture. We do this by letting the vendor be an unspecified unknown, or any. We also grab the target architecture, get the KDP host arch, and then merge the two before putting it back into the target.
Also change MH_PRELOAD to be use "unspecified unknown" (any) for the OS and vendor since these mach files can really be anything.
llvm-svn: 251579
|
|
|
|
|
|
| |
http://reviews.llvm.org/D14126
llvm-svn: 251547
|
|
|
|
|
|
| |
dump debugging.
llvm-svn: 251540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"lldb -c core".
To do this I added a few new ways to determine the OS from PT_NOTE notes in the ELF file:
1 - Look for "LINUX" notes which indicate "linux" should be the OS
2 - Look through the "CORE" notes with NT_FILE as the type and sniff data from the paths listed in this section. On Ubuntu they contain "/lib/x86_64-linux-gnu" which has the triple and allows us to set "linux" as the OS in the architecture returned from ObjectFileELF::GetArchitecture().
Setting the OS correctly allows us to get the triple correct so we can extract registers without asserting and killing LLDB.
Also use the data from the NT_FILE to set the main executable if one isn't set in ProcessElfCore::DoLoadCore().
llvm-svn: 251537
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Gdb-remote's async thread sent out the eBroadcastBitRunPacketSent message *before* actually
sending out the continue packet. Since it's this message the actually triggers the public state
transition, it could happen (and it did happen in TestAttachResume, which does an "process
interrupt" right after a continue) that we attempt to stop the inferior before it was actually
started (which obviously did not end well). This fixes the problem by moving the broadcast after
the packet was actually sent.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14083
llvm-svn: 251399
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14051
llvm-svn: 251386
|
|
|
|
|
|
|
|
| |
This avoids the need to query the PC for private resume operations (public resumes have the PC
from the bigger jStopInfo packet) and speeds up the stepping on an android target by about 10%
(it some cases even more).
llvm-svn: 251301
|
|
|
|
|
|
|
| |
This is just a trivial patch that corrects a couple of return value account to function's return type.
Also corrects typo in hardware breakpoint handler.
llvm-svn: 251269
|
|
|
|
|
|
| |
fix MSVC builds failures.
llvm-svn: 251170
|
|
|
|
|
|
| |
source/Plugins; other minor fixes.
llvm-svn: 251167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These changes aren't everything what is needed for the CMake target, but it's significantly approaching it.
These changes shouldn't effect the build process on other platforms.
Patch by Kamil Rytarowski, thanks!
Reviewers: joerg, brucem
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13711
llvm-svn: 251164
|
|
|
|
|
|
|
|
|
|
| |
* Use PTRACE_GETVFPREGS/PTRACE_SETVFPREGS to access the floating point
registers instead of the old PTRACE_GETFPREGS/PTRACE_SETFPREGS. The
new call is available since armv5.
* Work around a kernel issue in PTRACE_POKEUSER with reading out the full
register set, modifying the neccessary value and then writing it back.
llvm-svn: 251111
|
|
|
|
| |
llvm-svn: 251088
|
|
|
|
|
|
| |
http://reviews.llvm.org/D13881
llvm-svn: 250933
|
|
|
|
|
|
|
|
| |
source/Plugins; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13951
llvm-svn: 250925
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, labath.
Subscribers: jaydeep, dsanders, bhushan, sagar, nitesh.jain, emaste,lldb-commits.
Differential Revision: http://reviews.llvm.org/D13646
llvm-svn: 250801
|
|
|
|
|
|
|
|
|
|
| |
LLDB.framework.
This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find debugserver inside the selected Xcode.app on your system.
<rdar://problem/23167253>
llvm-svn: 250735
|