| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
source/Plugins; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13840
llvm-svn: 250721
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
o32 applications
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
|
|
|
|
|
|
|
|
| |
source/Plugins/Process/Utility; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13830
llvm-svn: 250593
|
|
|
|
|
|
| |
http://reviews.llvm.org/D13754
llvm-svn: 250474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
watchpoint_exceptions_received=before
llvm-svn: 250272
|
|
|
|
|
|
|
| |
We had an incorrect sign extension when castion from a pointer to an
lldb::addr_t what broke the watchpoint hit detection on arm.
llvm-svn: 250180
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InferiorCallPOSIX. It was
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
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, jingham.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, brucem,lldb-commits.
Differential Revision: http://reviews.llvm.org/D13548
llvm-svn: 249837
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- For x86_64-FreeBSD Platform:
-- LLDB now provides correct values of X87 FPU
Special Purpose Registers like fstat, ftag, fctrl etc..
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: emaste, mikesart, clayborg
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D13434
llvm-svn: 249379
|
|
|
|
| |
llvm-svn: 249206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
| |
GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the accessor functions to pickup the value from m_scalar of RegisterValue which is zero.
In this patch byte size and byte order of register value is set at the time of setting the value of the register.
llvm-svn: 249020
|
|
|
|
|
|
|
| |
This reverts commit r248985, as it was breaking all remote
expression-evaluating tests (on android at least).
llvm-svn: 248995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 248985
|
|
|
|
| |
llvm-svn: 248909
|
|
|
|
|
|
|
|
|
| |
.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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on iOS devices; fallout from Vince's cleanups made
in r237218 back in May. iOS native lldbs will call
StartDebugserverProcess() with a random port #
(see ProcessGDBRemote::LaunchAndConnectToDebugserver)
and neither side of this conditional expression should
be followed in that case.
I added an "if (in_port == 0) { ..." check around the
entire if/then/else and indented the block of code so
the diff looks larger than it really is.
<rdar://problem/21712643>
llvm-svn: 248343
|
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
Using response.IsUnsupportedResponse instead of !response.IsNormalResponse().
Reviewers: clayborg, labath
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D12876
llvm-svn: 247968
|
|
|
|
| |
llvm-svn: 247939
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
/qfThreadInfo"
This reverts commit r247773, because it breaks remote debugging support for lldb-server.
llvm-svn: 247783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|