To do this, I fixed the CPPLanguageRuntime::StripNamespacesFromVariableName() function to use a regular expression that correctly determines if the name passed to it is a qualfied C++ name like "a:🅱️:c" or "b::c". The old version of this function was treating '__54-[NSUserScriptTask executeWithInterpreter:arguments::]_block_invoke' as a match with a basename of ']_block_invoke'.
Also fixed a case in the by name lookup of functions where we wouldn't look for the full name if we actually tried to call CPPLanguageRuntime::StripNamespacesFromVariableName() and got an empty basename back.
<rdar://problem/18527866>
llvm-svn: 220432
New functions to give client applications to tools to discover target byte sizes
for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the
SBTarget class, since they seemed to be useful utilities to have.
Each new API has had a test case added.
http://reviews.llvm.org/D5867
llvm-svn: 220372
BreakpointLocation::ShouldStop. That worked but wasn't really right,
since there's nothing to guarantee that won't get called more than
once. So this change moves that responsibility to the StopInfoBreakpoint
directly, and then it uses the BreakpointSite to actually do the bumping.
Also fix a test case that was assuming if you had many threads running some
code with a breakpoint in it, the hit count when you stopped would always be
1. Many of the threads could have hit it at the same time...
<rdar://problem/18577603>
llvm-svn: 220358
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
r219978 fixed this test to work on Darwin, and removed the expected
failure decorator, but it then started running (and failing) on FreeBSD.
I'd think @dsym_test should skip the test on all non-Darwin operating
systems. It seems not to be the case, so for now skip it the same way as
done for other @dsym_test tests.
llvm-svn: 220219
This fix addresses a requirement on some Linux kernels that limits
a PTRACER to be an ancestor of the ptraced process. The fix in this
case is to have the inferior test exe explicitly allow any ptracer
to attach.
This fixes several ptrace-related issues that I did not see on a modified
kernel we used internally on my team.
See http://reviews.llvm.org/D5846 for details.
This fixes these previously failing tests on stock Ubuntu systems:
FAIL: LLDB (suite) :: TestGdbRemoteProcessInfo.py (Linux vagrant 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64)
FAIL: LLDB (suite) :: TestGdbRemoteAttach.py (Linux vagrant 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64)
FAIL: LLDB (suite) :: TestLldbGdbServer.py (Linux vagrant 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64)
FAIL: LLDB (suite) :: TestGdbRemoteKill.py (Linux vagrant 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64)
llvm-svn: 220181
Issues were:
1 - It isn't good to have more than one listener for the process events, just supply a listener at launch instead of making a one then have the process broadcaster add a new listener
2 - run in async mode
llvm-svn: 220113
function because of a '1u' making it a 32-bit value
when it really needed to be a 64-bit value. Trivial to fix
once I figured out what was going on.
clang static analzyer fixit.
llvm-svn: 220022
unreachable so we don't get warnings about them.
Completely initialize a structure instead of leaving some of its fields
potentially indeterminate (although in reality they would all be set
before use -- but the compiler warning doesn't know that).
clang warning.
llvm-svn: 220017
case. This test case style attempts to shed all
of the boilerplate that is required for test
cases, and let 80% of test cases use a much terser
syntax.
Inline testcases have much simplified python files
(the corresponding .py file should contain two
lines of code) and require no Makefile, because the
Makefile is generated automatically. Breakpoints
are set automatically and the indicated breakpoint
actions (specified after a magic //% comment) are
executed when the breakpoint is hit.
All other testcases are unaffected.
One thing I'm not really happy with yet is the way
multiple actions for the same line are specified.
I'm going to use lang/c/struct_types as a guinea
pig to develop this further.
llvm-svn: 219984
a number of warnings to be enabled. The one making the most noise
across the code base right now is CLANG_WARN_UNREACHABLE_CODE = YES.
llvm-svn: 219910
We've already created a FileSpec based on this local and
this code path would never be executed if it is an invalid
FilePath - but the static analyzer doesn't know this and I
want to placate it.
clang static analyzer fixit.
llvm-svn: 219890
an uninitialized value. In reality the code block that
initializes it and the code block that restores it will always
match up - but the analyzer doesn't know that and I want to
quiet it, so...
clang static analyzer fixit.
llvm-svn: 219869
After the recent migration of code out of Host.cpp, many
unnecessary headers were still being included. This prunes the
include list down to only what is still necessary.
llvm-svn: 219814
Recognise the SHT_NOBITS property in kalimba ELF, and determine this to be
of type zerofilled. Subsequently recognise this type to represent bytes
on the target's DATA address space, and therefore be sized accordingly.
llvm-svn: 219782
in GetFullUnwindPlanForFrame() - the code was mostly checking
that we had an active Process and ABI but not always.
clang static analyzer fixit.
llvm-svn: 219772
This implements Host::LaunchProcess for windows, and in doing so
does some minor refactor to move towards a more modular process
launching design.
The original motivation for this is that launching processes on
windows needs some very windows specific code, which would live
most appropriately in source/Host/windows somewhere. However,
there is already some common code that all platforms use when
launching a process before delegating to the platform specific
stuff, which lives in source/Host/common/Host.cpp which would
be nice to reuse without duplicating.
This commonality has been abstracted into MonitoringProcessLauncher,
a class which abstracts out the notion of launching a process using
an arbitrary algorithm, and then monitoring it for state changes.
The windows specific launching code lives in ProcessLauncherWindows,
and the posix specific launching code lives in ProcessLauncherPosix.
When launching a process MonitoringProcessLauncher is created, and
then an appropriate delegate launcher is created and given to the
MonitoringProcessLauncher.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5781
llvm-svn: 219731
Ed Maste