| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Base framework for inspecting RenderScript runtime details and helpers for various runtime actions on x86 and arm targets.
Differential Revision: http://reviews.llvm.org/D10151
llvm-svn: 238768
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10164
llvm-svn: 238767
|
| |
|
|
|
|
| |
No regression on testsuite. Comitted as obvious.
llvm-svn: 238761
|
| |
|
|
|
|
| |
This is the FreeBSD change for r238604.
llvm-svn: 238752
|
| |
|
|
|
|
|
|
|
|
| |
When the current address is pointing 1 (unit) over the end of a
section the we have to do a section lookup after making the adjusment
of the current address.
Differential revision: http://reviews.llvm.org/D10124
llvm-svn: 238737
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10153
llvm-svn: 238722
|
| |
|
|
| |
llvm-svn: 238629
|
| |
|
|
|
|
|
|
| |
llvm::sys::path::is_relative in PlatformAndroid::GetFile.
http://reviews.llvm.org/D10141
llvm-svn: 238624
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D10080
llvm-svn: 238623
|
| |
|
|
| |
llvm-svn: 238610
|
| |
|
|
|
|
| |
concatenate it with current working directory if needed.
llvm-svn: 238606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D9728.
Reviewers: ovyalov, zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9806
llvm-svn: 238605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10048
llvm-svn: 238599
|
| |
|
|
| |
llvm-svn: 238590
|
| |
|
|
|
|
|
| |
Fixing these two instances will require some work, so for now
I'm adding these 2 includes back to get the build working.
llvm-svn: 238587
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
|
| |
|
|
| |
llvm-svn: 238551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.
This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.
I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).
Test Plan: All tests pass on linux and osx.
Reviewers: ovyalov, clayborg, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10057
llvm-svn: 238549
|
| |
|
|
|
|
| |
std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around.
llvm-svn: 238541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
-Fix lldb test failures introduced by r238530
-This fix TestGdbRemoteAuxvSupport.py and TestLldbGdbServer.py
Test Plan:
./dotest -p TestGdbRemoteAuxvSupport.py
./dotest -p TestLldbGdbServer.py
Reviewers: clayborg, chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10116
llvm-svn: 238535
|
| |
|
|
| |
llvm-svn: 238533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qEcho:%s
where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received!
This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen:
--> "abc"
<-- <<<error: timeout>>>
Now we want to send "def" and get "DEF" back:
--> "def"
<-- "ABC"
We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands.
The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- "abc"
<-- "qEcho:1"
The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time...
In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
We then disconnect and say we lost connection.
We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- "qEcho:1"
Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug.
<rdar://problem/21082939>
llvm-svn: 238530
|
| |
|
|
| |
llvm-svn: 238499
|
| |
|
|
|
|
| |
This reverts commit 8cb47a2140f3e93a34597fc9f11c8cd96130076d.
llvm-svn: 238497
|
| |
|
|
|
|
|
|
| |
Cause build break.
This reverts commit 6d986061393f2863fec739e04412281148acc1f3.
llvm-svn: 238496
|
| |
|
|
|
|
|
|
|
|
| |
it an extern "C" function instead of a C++ function
so that Clang doesn't emit a mangled function reference.
Also removed the hack in ClangExpressionDeclMap that
works around this.
llvm-svn: 238476
|
| |
|
|
|
|
| |
to check for alternate manglings.
llvm-svn: 238475
|
| |
|
|
| |
llvm-svn: 238470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLDB on Windows should now be able to demangle Linux/Android symbols.
Also updated CxaDemangle.cpp to be compatible with MSVC.
Depends on D9949, D9954, D10048.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10040
llvm-svn: 238460
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In preparation for some changes to make this compatible with MSVC.
Reviewers: emaste, zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9949
llvm-svn: 238459
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D10082
llvm-svn: 238442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix FileSpec::Dump() to output denormalized path.
See D9942 for previous discussions.
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10077
llvm-svn: 238440
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10062
llvm-svn: 238433
|
| |
|
|
| |
llvm-svn: 238431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing
with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by
opening the pipe in the object constructor. The pipe will be automatically closed when the object
is destroyed.
Test Plan: Tests pass on linux.
Reviewers: clayborg, ribrdb
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10060
llvm-svn: 238423
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch by Tom Rix, with additional changes to sync whitespace/style with
PlatformLinux.cpp.
It is currently disabled pending kernel support.
Differential Revision: http://reviews.llvm.org/D9170
llvm-svn: 238420
|
| |
|
|
| |
llvm-svn: 238410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we wait()ed for events from the inferiors process group. This is resulted in a
failure if the inferior changed its process group in the middle of execution. To avoid this, I
pass -1 to the wait() call. The flag __WNOTHREAD makes sure we don't actually wait for events
from any process, but only the processes(threads) which are our children (or traced by us). Since
this happens on the monitor thread, which is dedicated to monitoring a single inferior, we will
be getting events only from this inferior.
Test Plan: All tests pass on linux. I have added a test to check the new functionality.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10061
llvm-svn: 238405
|
| |
|
|
|
|
|
|
|
|
| |
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
|
| |
|
|
|
|
|
|
|
|
|
|
| |
lldb_private::Process instances from ever destroying themselves: ProcessModID.m_mod_id was holding onto the last stop event with ProcessModID::SetStopEventForLastNaturalStopID(EventSP). This is a bad idea because ProcessEventData contains a strong refereence to the process. This is now fixed by calling ProcessModID::SetStopEventForLastNaturalStopID(EventSP()) to clear this event in Process::SetExitStatus() and in Process::Finalize().
This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes.
This process leak was previously worked around by closing the pipes when the communication channel was disconnected.
This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference.
llvm-svn: 238392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
|
| |
|
|
|
|
|
|
| |
nanoseconds.
<rdar://problem/21090231>
llvm-svn: 238334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info.
However in non-stop mode we can receive several stop reply packets in a sequence for different threads. As a result we need to use a container to hold them before they are processed.
This patch also changes the return type of CheckPacket() so we can detect async notification packets.
Reviewers: clayborg
Subscribers: labath, ted, deepak2427, lldb-commits
Differential Revision: http://reviews.llvm.org/D9853
llvm-svn: 238323
|
| |
|
|
|
|
|
|
|
|
| |
This change also get rid of an unused Debugger instance in
GDBRemoteCommunicationServerLLGS and the command interpreter from
lldb-platform what was used only for enabling logging.
Differential revision: http://reviews.llvm.org/D9876
llvm-svn: 238319
|
| |
|
|
|
|
|
|
| |
Apply r238009 to FreeBSD as well.
Differential Revision: http://reviews.llvm.org/D10037
llvm-svn: 238316
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9994
llvm-svn: 238314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
(different) Greg's patch, but I have added stronger synchronization to it to avoid races.
Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.
Test Plan: Prompt comes out alright. All tests still pass on linux.
Reviewers: clayborg, emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9823
llvm-svn: 238313
|
| |
|
|
| |
llvm-svn: 238312
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D9886
llvm-svn: 238308
|