detct unwind loops but there was a code path through there (using
architecture default unwind plans) that didn't do the check, and
could end up with an infinite loop unwind. Move that code into a
separate method and call it from both places where it is needed.
Also remove the use of ABI::FunctionCallsChangeCFA in that check.
I thought about it a lot and none of the architecutres that we're
supporting today can have a looping CFA.
Since the unwinder isn't using ABI::FunctionCallsChangeCFA() and
ABI::StackUsesFrames(), and the unwinder was the only reason
those methods exists, I removed them from the ABI and all its
plugins.
<rdar://problem/17364005>
llvm-svn: 216992
Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented.
Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too.
See the following for more details:
http://reviews.llvm.org/D4580http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html
Change by Paul Osmialowski.
llvm-svn: 216737
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
i386 eh_frame register numbering, encoding a darwin-specific
bug in the register numbering. Update the definitions to be
the correct values, Darwin can use the register numbers from
debugserver. Patch from Tong Shen.
llvm-svn: 215488
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
- Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms
- Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll
- More build fixes for Windows
The pending issues are that two Python modules, termios and pexpect are not available on Windows.
These are currently required for the Python command interpreter to be used from within LLDB.
llvm-svn: 212111
Also moves NativeRegisterContextLinux* files into the Linux directory.
These, like NativeProcessLinux, should only be built on Linux or a cross
compiler with proper headers.
llvm-svn: 212074
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
mistake in the lock acquistion in HistoryUnwind and HistoryThread.
We've got a deadlock with one use case of HistoryUnwind; I
need to figure out what lock ordering is causing this and fix
it for real.
<rdar://problem/17411904>
llvm-svn: 211541
to modify the same UnwindTable object simultaneously. Fix
HistoryThread and HistoryUnwind's mutex lock acqusition to
retain the lock for the duration of the operation instead of
releasing the temporary immediately.
<rdar://problem/17055023>
llvm-svn: 211241
RegisterSets are assumed to be terminated by this value. Loops over
register set values would fail without LLDB_INVALID_REGNUM terminating
the list. This change adjusts the static check to account for the
size of the register set regnum list being one larger than the expected
valid register set count.
llvm-svn: 210964
Also moved it into the lldb_private namespace.
The llgs branch is making use of this interface and its use is not
strictly limited to POSIX.
llvm-svn: 209016
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
When compiling on Linux with GCC 4.8, compilation would fail due to the use of
the offsetof macro. This is a standard macro, defined in stddef.h. Include
this header to ensure that offsetof is declared.
llvm-svn: 206702
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
Fix Windows build by adding JITLoaderGDB and ProcessElfCore.
RegisterContext: fixes for Windows build: sizeof(GPR::register) didn't work, switched to sizeof(((GPR*)NULL)->register).
llvm-svn: 203667
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
class. If we try to unwind a stack frame to find a caller stack
frame, and we fail to get a valid-looking frame, AND if the UnwindPlan
we used is an assembly-inspection based UnwindPlan, then we should
throw away the assembly-inspection UnwindPlan and try unwinding with
the architectural default UnwindPlan.
This code path won't be taken if eh_frame unwind instructions are available -
lldb will always prefer those once it's off the zeroth frame.
The problem I'm trying to fix here is the class of unwind failures that
happen when we have hand-written assembly on the stack, with no eh_frame,
and lldb's assembly parser fails to understand the assembly. People usually
write their hand-written assembly to follow the frame-pointer-preserving
conventions of the platform so the architectural default UnwindPlan will
often work. We won't have the spill location for most of the non-volatile
registers if we fall back to this, but it's better than stopping the unwind
prematurely.
This is a bit of a tricky change that I believe is correct, but if we get
unwinds that go of into the weeds / unwind bogus frames at the end of the
stack, I'll need to revisit it.
<rdar://problem/16099440>
llvm-svn: 201839
specify a list of functions which should be treated as trap handlers.
This will be primarily useful to people working in non-user-level
process debugging - kernels and other standalone environments.
For most people, the trap handler functions provided by the Platform
plugin will be sufficient.
<rdar://problem/15835846>, <rdar://problem/15982682>
llvm-svn: 201386
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
The former will set the Address object's offset to the load address value if
it is not present in any section; the latter will only set the Address object
if the load addr is contained in one of its sections.
<rdar://problem/15135987>
llvm-svn: 198469
its stack frame is a constructed, fake thing that may not conform
correctly to these rules. This fixes a problem where lldb couldn't
backtrace past an asynchronous signal handler (_sigtramp) frame on
a stack on Mac OS X.
<rdar://problem/15035673>
llvm-svn: 198450
The original code was not completely correct, but a form of
this check is necessary to avoid an infinite recursion on
some unwind cases where a function unwinds to itself with the
same CFA. Ashok thought the recursion would be caught in
RegisterContextLLDB but this one isn't - we still need it here.
<rdar://problem/15664282>
llvm-svn: 197761
