| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmortem) debugging. The minidump portion was replaced by a cross-platform
solution. This left the plugin split into a formerly "common" base classes and
the derived classes for live debugging. This extra layer made the code harder
to understand and work with.
This patch simplifies these class hierarchies by rolling the live debugging
concrete classes up to the base classes. Last week I posted my intent to make
this change to lldb-dev, and I didn't hear any objections.
This involved moving code and changing references to classes like
ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit,
and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before
this refactor for unrelated reasons.)
llvm-svn: 287770
|
|
|
|
|
|
|
|
| |
My script updated lldb::Errors, and I failed to fix it entirely
before pushing. This restore everything in lldb as it was before
r286561.
llvm-svn: 286565
|
|
|
|
|
|
|
|
|
| |
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25247
llvm-svn: 283344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Windows live process and minidump implementations of lldb_private::Process (ProcessWindowsLive::GetMemoryRegionInfo and ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The existing Windows implementations didn’t fill in the start and end addresses within MemoryRegionInfo. This patch fixes that and adds support for the new mapped flag on MemoryRegionInfo that says whether a memory range is mapped into the process address space or not.
The behaviour of both live and core implementations should match the behaviour documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should match the behaviour of the qMemoryRegionInfo query documented in lldb-gdb-remote.txt.
Reviewers: clayborg, amccarth
Subscribers: amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D22352
llvm-svn: 275778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces the C-style "void *" baton of the child process monitoring functions with a more
C++-like API taking a std::function. The motivation for this was that it was very difficult to
handle the ownership of the object passed into the callback function -- each caller ended up
implementing his own way of doing it, some doing it better than others. With the new API, one can
just pass a smart pointer into the callback and all of the lifetime management will be handled
automatically.
This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have
left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate
commit to reduce the scope of this change.
Reviewers: clayborg, zturner, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20106
llvm-svn: 269205
|
|
|
|
|
|
|
| |
r268544 moves all PDB reading code into a pdb namespace,
so LLDB needs to be updated to take this into account.
llvm-svn: 268545
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
|
|
|
|
|
|
| |
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/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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/D12252
llvm-svn: 245850
|