|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| | HostInfo::GetOSKernelDescription.
llvm-svn: 223737 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | section for x86_64 and i386 targets on Darwin systems.  Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it.  The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them.  There may need to be some bug fixing over the next couple weeks as
I exercise and test it further.  But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837> 
llvm-svn: 223625 | 
| | 
| 
| 
| | llvm-svn: 223498 | 
| | 
| 
| 
| 
| 
| 
| | This causes all deferred breakpoints to be correctly resolved as
the modules that they reside in are loaded.
llvm-svn: 223497 | 
| | 
| 
| 
| | llvm-svn: 223496 | 
| | 
| 
| 
| | llvm-svn: 223393 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This reverts commit 4a5ad2c077166cc3d6e7ab4cc6e3dcbbe922af86.
Windows doesn't support select() for pipe objects, and this also fails
to compile on Windows.  Reverting this until we can get it sorted out
to keep the windows build working.
llvm-svn: 223392 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This is a temporary workaround to get deferred breakpoint
resolution working until Bug 21720 is addressed.  Even with this
workaround, it will only resolve deferred breakpoints in the
executable module, and not in a shared library.
llvm-svn: 223273 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously if we got a DoDestroy while stopped at a breakpoint, we
would detach and then say the process had exited.  This is completely
wrong, as it resulted in the python script incorrectly assuming that
the process had actually exited and trying to delete the image, when
in fact it had done no such thing.
The fix employed here is that when we get a DoDestroy, we do 3 steps:
1) initiate a termination sequence on the process
2) If we were stopped handling an exception of any kind, mask it and
   let the program resume, causing the program to see the termination
   request and exit on its own.
3) Let the program exit normally, and close all of our handles before
   returning control back to DoDestroy.
This fixes Bug 21722 and Bug 21723.
llvm-svn: 223272 | 
| | 
| 
| 
| 
| 
| | http://reviews.llvm.org/D6490
llvm-svn: 223251 | 
| | 
| 
| 
| | llvm-svn: 223089 | 
| | 
| 
| 
| | llvm-svn: 222776 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them.  In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on
that same stack frame before it tries the fallback unwind plan
on the "next" or callee frame.
In RegisterContextLLDB::TryFallbackUnwindPlan, when we're
trying the fallback unwind plan to see if it is valid, make
sure we change all of the object ivars that might be used in
the process of fetching the CFA & caller's saved pc value 
and restore those if we decide not to use the fallback 
unwindplan.
<rdar://problem/19035079> 
llvm-svn: 222601 | 
| | 
| 
| 
| | llvm-svn: 222597 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | LLDB supports many different register numbering schemes, and these
are typically prefixed with an indicator that lets the user know
what numbering scheme is used.  The gcc numbering scheme is
prefixed with gcc, and there are similar ones for dwarf, gdb,
and gcc_dwarf.
LLDB also contains its own internal numbering scheme, but the enum
for LLDB's numbering scheme was prefixed differently.  This patch
changes the names of these enums to use the same naming scheme for
the enum values as the rest of the register kinds by removing gpr_
and fpu_ prefixes, and instead using lldb_ prefixes for all enum
values.
Differential Revision: http://reviews.llvm.org/D6351
Reviewed by: Greg Clayton
llvm-svn: 222495 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Running a diff against lldb-x86-register-enums.h and the file
modified in this patch, the two enums were completely identical.
Deleting one of them to reduce code noise.
llvm-svn: 222478 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This implements the skeleton of a RegisterContext for Windows.
In particular, this implements support only for x86 general purpose
registers.
After this patch, LLDB on Windows can perform basic debugging
operations in a single-threaded inferior process (breakpoint,
register inspection, frame select, unwinding, etc).
Differential Revision: http://reviews.llvm.org/D6322
Reviewed by: Greg Clayton
llvm-svn: 222474 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Process/ProcessPOSIX.cpp
and FreeBSD/ProcessMonitor.
http://reviews.llvm.org/D6240
llvm-svn: 222372 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | where it is retrieving the Return Address register contents
on a target where that's a thing.  If we fail to get a valid
RA, we force a switch to the fallback unwind plan.  This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211> 
llvm-svn: 222301 | 
| | 
| 
| 
| 
| 
| 
| 
| | Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type.  This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185 | 
| | 
| 
| 
| | llvm-svn: 222184 | 
| | 
| 
| 
| | llvm-svn: 222182 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously we were directly updating the thread list and stopping
and restarting the process every time threads were created.  With
this patch, we queue up thread launches and thread exits, resolve
these all internally, and only update the threads when we get an
UpdateThreadList call.  We now only update the private state on
an actual stop (i.e. breakpoint).
llvm-svn: 222178 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This creates a TargetThreadWindows class and updates the thread
list of the Process with the main thread.  Additionally, we
fill out a few more overrides of Process base class methods.  We
do not yet update the thread list as threads are created and/or
destroyed, and we do not yet propagate stop reasons to threads as
their states change.
llvm-svn: 222148 | 
| | 
| 
| 
| | llvm-svn: 222147 | 
| | 
| 
| 
| 
| 
| | reinterpret_cast from NativeProcessProtocol* to NativeProcessLinux*.
llvm-svn: 221906 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | RegisterContextLLDB.  I have core files of half a dozen tricky
unwind situations on x86/arm and they're all working pretty much
correctly at this point, but we'll need to keep an eye out for
unwinder regressions for a little while; it's tricky to get these
heuristics completely correct in all unwind situations.
<rdar://problem/18937193> 
llvm-svn: 221866 | 
| | 
| 
| 
| 
| 
| | with addresses that aren't designed to be column-aligned across multiple lines.
llvm-svn: 221810 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This sends notifications for module load / unload to the process
plugin, and also manages the state more accurately during the
loading sequence.
Similar work by Virgile Bello was referenced during the
implementation of this patch.
Differential Revision: http://reviews.llvm.org/D6224
llvm-svn: 221807 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Due to a previous multi-threaded design involving message
passing, we used message classes to pass event information
to the delegate.  Since the multi-threaded design has gone
away, we simplify this by passing event arguments as direct
function parameters, which is more clear and easier to
understand.
llvm-svn: 221806 | 
| | 
| 
| 
| 
| 
| 
| 
| | After r221575 TestCallStopAndContinue and TestCallThatRestarts started
crashing on FreeBSD with a null temporary_module_sp in
RegisterContextLLDB::InitializeNonZerothFrame().
llvm-svn: 221805 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The addition of RegisterNumber introduced a bug where if the PC is stored in a
return address register, such as on ARM and PowerPC, this register number is
retrieved and used, but never checked in the row if it's saved.  Correct this by
setting the variable that's used to the new register number.
Patch by Jason Molenda.
llvm-svn: 221790 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add
full stack unwind support to the PowerPC/PowerPC64 ABI.  Also, add a new
register set for powerpc32-on-64, so the register sizes are correct.  This also
requires modifying the ProcessMonitor to add support for non-uintptr_t-sized
register values.
Reviewers: jasonmolenda, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6183
llvm-svn: 221789 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA).  LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.
Discussed with Jason Molenda, who also provided the initial patch for this.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D6182
llvm-svn: 221788 | 
| | 
| 
| 
| 
| 
| | RegisterContextLLDB a bit more in a few places.
llvm-svn: 221677 | 
| | 
| 
| 
| 
| 
| | http://reviews.llvm.org/D6158
llvm-svn: 221647 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This patch implements basic support for stopping at breakpoints
and resuming later.  While a breakpoint is stopped at, LLDB will
cease to process events in the debug loop, effectively suspending
the process, and then resume later when ProcessWindows::DoResume
is called.
As a side effect, this also correctly handles the loader breakpoint
(i.e. the initial stop) so that LLDB goes through the correct state
sequence during the initial process launch.
llvm-svn: 221642 | 
| | 
| 
| 
| | llvm-svn: 221637 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | it in RegisterContext.cpp.
There's a lot of bookkeeping code in RegisterContextLLDB where it has
to convert between different register numbering schemes and it makes 
some methods like SavedLocationForRegister very hard to read or
maintain.  Abstract all of the details about different register numbering
systems for a given register into this new class to make it easier 
to understand what the method is doing.
Also add register name printing to all of the logging -- that's easy to
get now that I've got an object to represent the register numbers.
There were some gnarly corner cases of this method that I believe
I've translated correctly - initial testing looks good but it's
possible I missed a corner case, especially with architectures which
uses a link-register aka return address register like arm32/arm64.
Basic behavior is correct but there are a lot of corner casese that are
handled in this method ...
llvm-svn: 221577 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.
Also add a backtrace test with an attempt to elicit this 
particular layout.  It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting.  We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.
<rdar://problem/16051613> 
llvm-svn: 221575 | 
| | 
| 
| 
| | llvm-svn: 221570 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Originally the idea was that we would queue requests to a master
thread that would dispatch them to other slave threads each
responsible for debugging an individual process.  This might make
some scenarios more scalable and responsive, but for now it seems
to be unwarranted complexity for no observable benefit.
llvm-svn: 221561 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | In the llgs world, ProcessWindows will eventually go away and
we'll implement a different protocol.  This patch decouples
ProcessWindows from the core debug loop so that this transition
will not be more difficult than it needs to be.
llvm-svn: 221405 | 
| | 
| 
| 
| 
| 
| | launching LLGS process. Differential Revision: http://reviews.llvm.org/D6105
llvm-svn: 221324 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Renamed monitor -> driver, to make clear that the implementation here
is in no way related to that of other process plugins which have also
implemented classes with similar names such as DebugMonitor.
Also created a DebugEventHandler interface, which will be used by
implementors to get notified when debugging events happen in the
inferiors.
llvm-svn: 221322 | 
| | 
| 
| 
| 
| 
| 
| | so it doesn't try the arch default if a comiler-generated (eh_frame,
compact unwind info) based unwind plan has failed.
llvm-svn: 221239 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.
This fix is for <rdar://problem/18683658>.  
I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios 
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719> 
that I've fixed over the last 6-9 months.
llvm-svn: 221238 | 
| | 
| 
| 
| | llvm-svn: 221232 | 
| | 
| 
| 
| | llvm-svn: 221231 |