| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 160338
|
|
|
|
| |
llvm-svn: 160212
|
|
|
|
| |
llvm-svn: 160158
|
|
|
|
|
|
|
|
|
| |
Also remove our dependency on UIKit & AppKit.
Cleaned up the project files a bit.
<rdar://problem/11814498>
llvm-svn: 160147
|
|
|
|
|
|
|
|
| |
path passed with -w
Test this functionality.
llvm-svn: 160130
|
|
|
|
| |
llvm-svn: 159929
|
|
|
|
| |
llvm-svn: 159798
|
|
|
|
| |
llvm-svn: 158890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it, rather
than being given the pthread_mutex_t from the Mutex and locks that. That allows us to
track ownership of the Mutex better.
Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)
llvm-svn: 158240
|
|
|
|
|
|
|
|
| |
separate process group, otherwise ^C will both cause us to try to Stop it manually, AND send it a SIGINT, which can confuse us.
rdar://problem/11369230
llvm-svn: 157791
|
|
|
|
| |
llvm-svn: 157456
|
|
|
|
|
|
| |
to evaluate an expression with no target.
llvm-svn: 157110
|
|
|
|
| |
llvm-svn: 157090
|
|
|
|
| |
llvm-svn: 157040
|
|
|
|
|
|
| |
Restore Xcode as a valid white list client using the XPC root launcher
llvm-svn: 157012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on it.
TestBackticksWithoutATarget.BackticksWithNoTargetTestCase was calling
GetDummyTarget() when executing for x86_64. When performing session
tearDown, it would get destroyed (and everything would be invalid (arch,
etc).
Then the test would run for i386. The dummy target wasn't being
reinitialized and was invalid. lldb complained that 'current process state
is unsuitable for expression parsing'.
llvm-svn: 156994
|
|
|
|
| |
llvm-svn: 156971
|
|
|
|
| |
llvm-svn: 156887
|
|
|
|
|
|
| |
Fixed the test suite not working on i386 due to recent default arch detection changes.
llvm-svn: 156796
|
|
|
|
|
|
|
|
|
|
|
|
| |
"lldb -a i386" doesn't set the calculator mode correctly if run on a 64 bit system.
The previous logic always used the current host architecture, not the default architecture. The default arch gets set into a static varaible in lldb_private::Target when an arch is set from the command line:
lldb -a i386
We now use the default arch correctly.
llvm-svn: 156680
|
|
|
|
|
|
| |
Restore expressions with no target.
llvm-svn: 156669
|
|
|
|
|
|
|
|
| |
On Lion, because the rights initially doesn't exist in /etc/authorization, if an admin user logs in and uses lldb within the first 5 minutes, it is possible to do AuthorizationCopyRights on LaunchUsingXPCRightName and get the rights back. As another security measure, we make sure that the LaunchUsingXPCRightName rights actually exists.
Removed Xcode as the user of the XPC service to shrink the security surface area.
llvm-svn: 156424
|
|
|
|
|
|
|
|
| |
We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights.
As well, refactored a bit so that control flow is easier to read for other folks. Added more comments.
llvm-svn: 156423
|
|
|
|
| |
llvm-svn: 156359
|
|
|
|
| |
llvm-svn: 156264
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
|
|
|
|
|
|
|
|
|
| |
the mutex handed in, not the m_mutex_ptr that you've set to NULL...
Rework the Host.cpp::ThreadNameAccessor to use ThreadSafeSTLMap - we've got it so we might as well use it. Also works around a problem with the
Mutex::Locker class raising fallacious asserts in debug mode when used with pthread_mutex_t's that weren't backed by Mutex objects.
llvm-svn: 156193
|
|
|
|
| |
llvm-svn: 155687
|
|
|
|
| |
llvm-svn: 155527
|
|
|
|
| |
llvm-svn: 155272
|
|
|
|
| |
llvm-svn: 155093
|
|
|
|
| |
llvm-svn: 154975
|
|
|
|
| |
llvm-svn: 154887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
output from them along with the status and signal:
Error
Host::RunShellCommand (const char *command,
const char *working_dir,
int *status_ptr,
int *signo_ptr,
std::string *command_output_ptr,
uint32_t timeout_sec);
This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.
llvm-svn: 154730
|
|
|
|
|
|
|
|
| |
checking for LLDB mutex validity are static so
that entries put in there actually persist between
calls to error_check_mutex.
llvm-svn: 154727
|
|
|
|
|
|
| |
initialized.
llvm-svn: 154710
|
|
|
|
| |
llvm-svn: 154650
|
|
|
|
|
|
| |
we always check if a mutex is valid prior to doing stuff with it. We also track when mutexes are initialized and destroyed and keep these in sets that can very subsequent pthread_mutex_XXX API calls.
llvm-svn: 154637
|
|
|
|
|
|
|
|
| |
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
|
|
|
|
| |
llvm-svn: 154252
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nanoseconds in 32-bit expression would cause pthread_cond_timedwait
to time out immediately. Add explicit casts to the TimeValue::TimeValue
ctor that takes a struct timeval and change the NanoSecsPerSec etc
constants defined in TimeValue to be uint64_t so any other calculations
involving these should be promoted to 64-bit even when lldb is built
for 32-bit.
<rdar://problem/11204073>, <rdar://problem/11179821>, <rdar://problem/11194705>.
llvm-svn: 154250
|
|
|
|
|
|
|
|
|
|
|
|
| |
from code run on the private state thread. To do that we have to
spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do
that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference.
This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug
server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call.
llvm-svn: 154230
|
|
|
|
| |
llvm-svn: 154148
|
|
|
|
|
|
| |
of a superfluous 'default' label.
llvm-svn: 153943
|
|
|
|
| |
llvm-svn: 153823
|
|
|
|
|
|
| |
malloc'ed string array.
llvm-svn: 153785
|
|
|
|
| |
llvm-svn: 153630
|
|
|
|
| |
llvm-svn: 153374
|
|
|
|
| |
llvm-svn: 153365
|
|
|
|
| |
llvm-svn: 153298
|