| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about.
This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context.
Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps.
Differential Revision: http://reviews.llvm.org/D17465
llvm-svn: 261808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some circumstances (notably, certain minidumps), the thread CONTEXT does not have values for the
control registers (EIP, ESP, EBP, EFLAGS). There are flags in the CONTEXT which indicate which
portions are valid, but those flags weren't checked. The old code would not detect this and give a
garbage value for the register. The new code will log the problem and return an error.
I consolidated the error checking and logging into a helper function, which makes the big switch
statement easier to read and verify.
Ran tests to ensure this doesn't break anything. Manually verified that a minidump without info on
the control registers now indicates the problem instead of giving bad information.
Differential Review: http://reviews.llvm.org/D17152
llvm-svn: 260559
|
|
|
|
|
|
| |
Log message was wrong because an argument was missing.
llvm-svn: 259793
|
|
|
|
|
|
|
|
| |
I don't understand how this worked before, but this fixes the recent test regressions on Windows in TestConsecutiveBreakpoints.py.
Differential Revision: http://reviews.llvm.org/D16825
llvm-svn: 259605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to rL256704 and rL256707, fix a few text files which were
accidentally checked in with DOS line endings, or mixed line endings.
Reviewers: jingham, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16027
llvm-svn: 257361
|
|
|
|
|
|
| |
cross-platform test.
llvm-svn: 257186
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15359
llvm-svn: 255083
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15218
llvm-svn: 254780
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14591
llvm-svn: 252950
|
|
|
|
|
|
| |
No build bots build x64 on Windows yet, but this was spotted by another developer who emailed me directly.
llvm-svn: 252100
|
|
|
|
|
|
| |
dump debugging.
llvm-svn: 251540
|
|
|
|
| |
llvm-svn: 249206
|
|
|
|
| |
llvm-svn: 248909
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
|
|
|
| |
llvm-svn: 247206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 246579
|
|
|
|
| |
llvm-svn: 246578
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12507
llvm-svn: 246558
|
|
|
|
| |
llvm-svn: 246302
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12252
llvm-svn: 245850
|
|
|
|
|
|
|
|
| |
There might be an underlying race condition here that should be
figured out, but this at least prevents the crash for the time
being and doesn't appear to have any adverse effects.
llvm-svn: 245626
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12126
llvm-svn: 245495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit moves the Windows DyanamicLoader to the common DynamicLoader
directory. This is required to remote debug Windows targets.
This commit also initializes the Windows DYLD plugin in
SystemInitializerCommon (similarly to both POSIX and MacOSX DYLD
plugins) so that we can automatically instantiate this class when
connected to a windows process.
Test Plan: Build.
Reviewers: zturner
Subscribers: lldb-commits, abdulras
Differential Revision: http://reviews.llvm.org/D10882
llvm-svn: 241697
|
|
|
|
|
|
| |
TestCreateAfterAttach.py).
llvm-svn: 241475
|
|
|
|
| |
llvm-svn: 240157
|
|
|
|
| |
llvm-svn: 239284
|
|
|
|
| |
llvm-svn: 238787
|
|
|
|
| |
llvm-svn: 237945
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9801
Reviewed by: Adrian McCarthy
llvm-svn: 237817
|
|
|
|
| |
llvm-svn: 237637
|
|
|
|
| |
llvm-svn: 237415
|
|
|
|
| |
llvm-svn: 237392
|
|
|
|
| |
llvm-svn: 236776
|
|
|
|
|
|
|
| |
With this patch, LLDB can debug x64 executables on Windows with
the same level of functionality as for x86 executables.
llvm-svn: 235935
|
|
|
|
| |
llvm-svn: 234607
|
|
|
|
| |
llvm-svn: 234422
|
|
|
|
| |
llvm-svn: 234007
|
|
|
|
| |
llvm-svn: 234005
|
|
|
|
|
|
|
|
| |
This replaces the home-grown initialization mechanism used before.
Differential Revision: http://reviews.llvm.org/D8760
llvm-svn: 233999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were a couple of real bugs here regarding error checking and
signed/unsigned comparisons, but mostly these were just noise.
There was one class of bugs fixed here which is particularly
annoying, dealing with MSVC's non-standard behavior regarding
the underlying type of enums. See the comment in
lldb-enumerations.h for details. In short, from now on please use
FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which
contain values larger than can fit into a signed integer.
llvm-svn: 233943
|
|
|
|
|
|
|
| |
No functional change here, only deletes unnecessary headers
and moves one function's body from the .h file to the .cpp.
llvm-svn: 231145
|
|
|
|
|
|
|
| |
SWIG doesn't like enum : unsigned. Revert this until I can
fix this in a way that swig likes.
llvm-svn: 230531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DebuggerThread was detecting the launch error, but it was
ignored by ProcessWindows::DoLaunch, causing LLDB to wait forever
in the debugger loop.
This fixes the test case that explicitly attempts to launch a
process from a non-existant path.
Patch by Adrian McCarthy
Differential Revision: http://reviews.llvm.org/D7874
llvm-svn: 230523
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier this week I was able to get clang-cl on Windows to be
able to self host. This opened the door to being able to
get a whole new slew of warnings for the Windows build.
This patch fixes all of the warnings, many of which were real
bugs.
llvm-svn: 230522
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CopyContext is necessary to safely get the XState, but LLDB doesn't currently
use the XState. CopyContext is available as of Windows 7 SP1, so it can't be
used on Vista. Furthermore, it requires the Windows 8 SDK it compile,
making the baseline for compiling and running LLDB higher than necessary.
Patch by: Adrian McCarthy
Reviewed by: Zachary Turner
Differential Revision: http://reviews.llvm.org/D7572
llvm-svn: 229710
|
|
|
|
| |
llvm-svn: 226742
|