the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
The thread resume block is executed in the normal flow of thread
state queued event processing. The tests verify that it is executed
when we track the thread to be stopped and skipped when we track
it to already be running.
llvm-svn: 218638
Also added a test for the reset handling. The reset/state clearing happens
as a processed queue event. The only diff vs. standard processing is that
the exec clears the queue before queueing the activity to clear internal state.
i.e. once we get an exec, we really stop doing any other queue-based activity.
llvm-svn: 218629
works, as do breakpoints, run and pause, display zeroth frame.
See
http://reviews.llvm.org/D5503
for a fuller description of the changes in this commit.
llvm-svn: 218596
A new thread arriving while a pending signal notification
is outstanding will (1) add the new thread to the list of
stops expected before the deferred signal notification is
fired, (2) send a stop request for the new thread, and
(3) track the new thread as currently running.
llvm-svn: 218578
See http://reviews.llvm.org/D5495 for more details.
These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk
build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in
github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}.
llvm-svn: 218568
Tested two pending stops before notification, where one of the pending stop
requirements was already known to be stopped.
Tested pending thread stop before notification, then reporting thread with
pending stop died and verifies pending notification is made.
llvm-svn: 218559
Glad I did - caught a bug where the auto variable was not a reference
to a set and instead was a copy. I need to review rules on that!
llvm-svn: 218558
This change does the following:
* Remove test/c++/...
* Add gtest.
* Add gtest/unittest directory for unittesting individual classes.
* Add an initial Plugins/Process?linux/ThreadStateCoordinatorTest.cpp.
- currently failing a test (intentional).
- added a bare-bones ThreadStateCoordinator.cpp to Plugins/Process/Linux,
more soon. Just enough to prove out running gtest on Ubuntu and MacOSX.
* Added recursive make machinery so that doing a 'make' in gtest/ is
sufficient to kick off the existing test several directories down.
- Caveat - I currently short circuit from gtest/unittest/Makefile directly to
the one and only gtest/unittest/Plugins/Process/Linux directory. We'll need
to add the intervening layers. I haven't done this yet since to fix the
Xcode test failure correspondence, I may need to add a python layer which
might just handle the directory crawling.
* Added an Xcode project to the lldb workspace for gtest.
- Runs the recursive make system in gtest/Makefile.
- Default target is 'test'. test and clean are supported.
- Currently does not support test failure file/line correspondence.
Requires a bit of text transformation to hook that up.
llvm-svn: 218460
See http://reviews.llvm.org/D5486 for more details.
I was tracking a problem where llgs on linux would not pick up any environment variables. On OSX there is a virtual function PlatformDarwin::GetEnvironment() which correctly sets up the list of environment variables. On linux llgs it defaults to a base class default implementation which clears the list.
I moved the OSX implementation down to PlatformPOSIX. This fixes my problem on linux still works properly on OSX.
Change by Shawn Best.
Slight tweak to convert 'virtual' to 'override' in PlatformDarwin.h virtual method override by Todd.
Tested:
Ubuntu 14.04 x86_64, cmake/ninja build + tests.
MacOSX 10.9.5 x86_64, Xcode 6.1 Beta build + tests.
llvm-svn: 218424
See thread started here for motivation:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-September/005225.html
This change enables the ability to set breakpoints in ccache-based and executables that
make use of preprocessed source files. This ability existed in lldb before, but was off
by default.
Change by Doug Snyder.
llvm-svn: 218405
was broken in r214984 by the addition of an unconditional error
return at the start of the code block handling this method. Remove
the errant lines.
<rdar://problem/18416691>
llvm-svn: 218291
requirement for a command instead of the smallest. e.g. if a command
requires a Target, Process, Thread, and Frame, and none of those
are available, report the largest -- Target -- as being missing
instead of the smallest -- Frame.
Patch by Paul Osmialowski.
llvm-svn: 218181
platform locations. We didn't always do an exhaustive search through all the
platform locations, so we would have to read some files out of memory even though
they existed in the exploded shared cache or SDK.
<rdar://problem/18385947>
llvm-svn: 218157
that would clear the module list, and then put it back by hand. But we forgot to
also put its sections back in the target SectionList, so we would jettison it as
unloaded when we finished handling the first real load event. Add its sections.
<rdar://problem/18385947>
llvm-svn: 218156
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case
llvm-svn: 218132
The $A handler was unnecessarily waiting for the launched app to hit a stop
before returning. Removed this code.
Renamed the llgs inferior launching code to LaunchProcessForDebugging ()
to prevent it from possibly being mistaken as code that lldb-platform uses
to launch a debugserver process. We probably want to look at breaking out
llgs-specific and lldb-platform-specific code into separate derived classes,
with common code in a shared base class.
llvm-svn: 218075
The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If we do this again, we cause binary packets to lose bytes.
This allows lldb-platform to be able to upload binaries and debug them remotely.
llvm-svn: 218002
% lldb ios-executable
(lldb) platform connect connect://localhost:11111
Prior to this fix, the host platform would be selected even though the target was using the ios-remote platform.
llvm-svn: 217963
The problem was the read_func we were supplying to the interactive interpreter wasn't stripping the newline from the end of the string. Now it does and multi-line python scripts can be typed in Xcode.
<rdar://problem/17696438>
llvm-svn: 217843
This allows us to fixup the address of the symbol as soon as we parse it
so that lldb is not confused thinking there are two different symbols in
the binary (one with the thumb bit, one without). Also, differentiating
between THUMB and ARM symbols allows the debugger to place the right
type of breakpoint.
Change by Stephane Sezer.
llvm-svn: 217841
There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool.
See http://reviews.llvm.org/D5302 for more details.
Change by Shawn Best.
llvm-svn: 217818
There are target pointer members in struct jit_code_entry and jit_descriptor.
Data layout of those structures should be decided by target, not host.
This fixes JITLoaderGDB for 64-bit host and 32-bit target.
See http://reviews.llvm.org/D5339 for more details.
Change by Tong Shen.
llvm-svn: 217816
Also, in case they don't define any, change the default from "Run Python function <blah>" into "For more information run help <blah>"
The core issue here is that Python only allows one docstring per function, so we can't really attach both a short and a long help to the same command easily
There are alternatives but this is not a pressing enough concern to go through the motions quite yet
Fixes rdar://18322737
llvm-svn: 217795
ELF objects contain marker symbols to differentiate between ARM and
THUMB functions. Instead of storing them internally and having garbage
show up when symbols are searched for by the user, we can just skip them
and not store them at all, as we never actually need them.
Change by Stephane Sezer.
Tested:
Ubuntu 14.04 x86_64
MacOSX 10.9.4 x86_64
llvm-svn: 217782
Instead of forcing the remote arch type to MachO all the time, we
inspect the OS/vendor that the remote debug server reports and use it to
set the arch type to MachO, ELF or COFF accordingly.
See thread here for more context:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140915/012968.html
Change by Stephane Sezer.
Tested:
MacOSX 10.9.4 x86_64
Ubuntu 14.04 x86_64
llvm-svn: 217779
This is useful for checking inconsistencies between what the remote debug server thinks we are debugging and we think we are debugging. This follows the check for pointer byte size done just above.
Change by Stephane Sezer.
Tested:
Ubuntu 14.04 x86_64, llvm-3.5-built lldb
MacOSX 10.9.4, Xcode-Beta(2014-09-09)-built lldb.
llvm-svn: 217773
Jim Ingham