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
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
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
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
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
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
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
This patch corrects the number of bytes of debug register resources which are written while installing or removing a breakpoint using ptrace interface on arm64 targets.
Differential revision: http://reviews.llvm.org/D12522
llvm-svn: 250700
For o32 applications on mips we were getting segmentation fault while launching lldb-server because of overwritting stack when using elf_gregset_t in DoWriteRegisterValue.
We are now using the GPR_mips_linux buffer in DoWriteRegisterValue as done in DoReadRegisterValue also, which solves the above issue.
llvm-svn: 250696
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
disabled the use of the jThreadGetExtendedInfo packet which is used
to retrieve additional information about a thread, such as the QoS
setting for that thread on darwin systems.
Re-enable the use of the jThreadGetExtendedInfo packet, and add
some quick tests to the TestQueues mac test case which will verify
that we can retrieve the QoS names for these test threads.
<rdar://problem/22925096>
llvm-svn: 250364
Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the correct value depending on the platform, and use
that everywhere instead.
llvm-svn: 250331
Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it more compatible with the old $m packet. This allows
us to use almost the same code for handling both packet types. I have verified that debugserver
correctly handles $x packets even without the leading "0x". I have added a test which verifies
that the stub returns the same memory contents for both kinds of memory reads ($x and $m).
Reviewers: tberghammer, jasonmolenda
Subscribers: iancottrell, lldb-commits
Differential Revision: http://reviews.llvm.org/D13695
llvm-svn: 250295
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
Summary:
EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't
implemented or used anywhere, so remove them from the Hexagon and POSIX
Dynamic Loaders as well as the FreeBSD process.
Reviewers: clayborg, labath, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D13581
llvm-svn: 249840
when they introduced android testsuite regressions. Pavel has run the
testsuite against the updated patch and it completes cleanly now.
The original commit message:
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 249755
* 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
Abhishek Aggarwal