This test was very inconspicuosly skipped on linux, when it was crashing for local debugging. It
seems to work fine with LLGS, so I'm enabling it.
llvm-svn: 238816
The problem was the mutex was only protecting the setting of m_exit_string and m_exit_string, but this function relies on the m_private_state being set to eStateExited in order to prevent more than 1 client setting the exit status. We want to only allow the first caller to succeed.
On MacOSX we have a thread that reaps the process we are debugging, and we also have a thread that monitors the debugserver process. When a process exists, the ProcessGDBRemote::AsyncThread() would set the exit status to the correct value and then another thread would reap the debugserver process and they would often both end up in Process::SetExitStatus() at the same time. With the mutex at the top we allow all variables to be set and the m_private_state to be set to eStateExited _before_ the other thread (debugserver reaped) can try to set th exist status to -1 and "lost connection to debugserver" being set as the exit status.
This was probably an issue for lldb-server as well and could very well cleanup some tests that might have been expecting a specific exit status from the process being debugged.
llvm-svn: 238794
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
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
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
Skip the g++ 4.6 test if we're not going to build any C++ source.
If a test has C++ source files we automatically determine which C++
compiler to use based on $CC (for example, clang++ if CC=clang).
However, this is not done for tests without C++ source and CXX will
be GNU make's default of g++. This produces suprious "g++: not found"
errors in testrun output on systems without a gcc/g++.
Differential Revision: http://reviews.llvm.org/D10122
llvm-svn: 238603
If get_stopped_thread(... eStopReasonSignal) returns no thread, the
thread.IsValid assertion would throw AttributeError: 'NoneType' object
has no attribute 'IsValid'.
Differential Revision: http://reviews.llvm.org/D10123
llvm-svn: 238600
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
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
Summary:
Old Android devices, for example API 16, do not have the "readlink"
command. To take care of such devices, this commit changes to use "ls -l"
instead of "readlink" to get the lldb-server exe path.
The tests fixed with this change for an Android API 16 arm device are:
TestGdbRemoteAttach
TestGdbRemoteAuxvSupport
TestGdbRemoteExpeditedRegisters
TestGdbRemoteKill
TestGdbRemoteProcessInfo
TestGdbRemoteSegFault
TestGdbRemoteThreadsInStopReply
TestGdbRemote_qThreadStopInfo
Further, all tests in TestLldbGdbServer pass (previously erroring out),
except one which times out.
Test Plan:
Run dosep.py with 8 test threads targetting Android API 16
device.
Reviewers: vharron, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10107
llvm-svn: 238532
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
Summary:
-Buildbot parser depends on this line as start flag
-Will remove the dependency from buildbot parser, but it takes some time to take effect
-Will remove this line from printout after buildbot master reconfig
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10110
llvm-svn: 238527
Summary:
Using `(match){3}` instead of `matchmatchmatch`.
This is an update to D10078.
Test Plan: no change in test behavior.
Reviewers: clayborg, sivachandra
Reviewed By: sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10094
llvm-svn: 238510
Summary:
- This test cause Python crash randomly on darwin builder
- Tracked by bug 'llvm.org/pr23669'
Test Plan: ./dotest.py -m --executable /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/lldb --framework /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/LLDB.framework -A x86_64 -C clang -p TestThreadStates.py
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10053
llvm-svn: 238495
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
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
The test invokes the 'targetname' test command before setting a
target executable, which caused Python to raise TypeError: cannot
concatenate 'str' and 'NoneType' objects.
llvm.org/pr23686
llvm-svn: 238425
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
if the test fails for some reason, we can end up leaking a process. This has a tendency to
confuse the buildbots. I have added a cleanup hook to make sure we cleanup the child.
llvm-svn: 238421
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
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
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
Summary:
Before:
AssertionError: False is not True : Process is launched successfully
After:
AssertionError: False is not True : Command 'run a.out' failed.
>>> error: invalid target, create a target using the 'target create' command
>>> Process could not be launched successfully
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, vharron
Differential Revision: http://reviews.llvm.org/D9948
llvm-svn: 238363
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
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
A DW_TAG_subprogram entry can contain a reference to a
DW_AT_abstract_origin entry instead of duplicating the information
from it (e.g.: name) when the same function is inlined in some case
and not inlined in other cases.
This CL fixes name parsing for the case when the DW_TAG_subprogram
for the non inlined version contains just a reference to the
DW_AT_abstract_origin entry instead of the full information.
Differential revision: http://reviews.llvm.org/D10034
llvm-svn: 238307
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
move all core files to the session dir after all tests have completed
TEST PLAN
Run tests. Force a timeout by decreasing a timeout
export LLDB_EVENTS_TIMEOUT=10s
./dosep.py
Differential Revision: http://reviews.llvm.org/D9905
llvm-svn: 238281
Using the adb push protocol is significantly faster than the current method of
sending the hex encoded file data for the remote to write to the file.
Test Plan:
Tests continue to pass - and much faster (e.g. TestSBValuePersist.py takes 10s
down from 4m51s on mac -> android)
Differential Revision: http://reviews.llvm.org/D9943
llvm-svn: 238274
The tests are xfail'ed on Windows, but would still error out since
they were importing pexpect at global scope. This way the tests
will correctly report as unsupported.
llvm-svn: 238249
On non-Windows platforms, os.rename() will silently replace the
destination file if it already exists. On Windows, it doesn't do
this, and the filesystem has no mechanism to simulate the same type
of atomic rename operation. So on Windows, delete the file first
before calling os.rename().
llvm-svn: 238239
We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled.
Converted all locations that used XML over to using the host XML implementation.
Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet.
<rdar://problem/21090173>
llvm-svn: 238224
This change reorganize the register read/write code inside lldb-server on Linux
with moving the architecture independent code into a new class called
NativeRegisterContextLinux and all of the architecture dependent code into the
appropriate NativeRegisterContextLinux_* class. As part of it the compilation of
the architecture specific register contexts are only compiled on the specific
architecture because they can't be used in other cases.
The purpose of this change is to remove a lot of duplicated code from the different
register contexts and to remove the architecture dependent codes from the global
NativeProcessLinux class.
Differential revision: http://reviews.llvm.org/D9935
llvm-svn: 238196
If binding to port 0 is selected, the actual port is printed.
This improves the reliability of platform startup by ensuring that
a free port can be found.
TEST PLAN
./lldb-server platform --listen *:0
Listening for a connection from <port-number>...
Will appear on stdout (with other stuff potentially)
llvm-svn: 238173
The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat.
Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit().
Now we aren't leaking file descriptors and the stand alone test suite should run much better.
llvm-svn: 238089
This test takes over 5 minutes to run just by itself, and everything
fails anyway, so it doesn't make sense to keep it running for now.
llvm-svn: 238040
Summary: This enables correct handling of real time signals by lldb.
Test Plan: Added a test that verifies handling of SIGRTMIN
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9911
llvm-svn: 238009
Summary:
The current sleep duration is not sufficient for Android.
[[ Its a completely different investigation as to why Android needs longer
sleep durations for this test. ]]
Test Plan: dotest.py -p TestLldbGdbServer on Android and local linux.
Reviewers: chaoren
Reviewed By: chaoren
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9926
llvm-svn: 237981
`lock` depends on `fcntl`, which doesn't exist on Windows. Until
someone implements an equivalent locking mechanism on Windows, we
can't have lock imported globally.
llvm-svn: 237946
SUMMARY
dosep.py starts lots and lots of dotest instances.
This option helps you find if two (or more) dotest instances are using
the same directory at the same time.
Enable it to cause test failures and stderr messages if dotest
instances try to run in the same directory simultaneously.
It is disabled by default because it litters the test directories with
".dirlock" files
TEST PLAN
Set lldbtest.debug_confirm_directory_exclusivity = True
run ./dosep.py
Differential Revision: http://reviews.llvm.org/D9868
llvm-svn: 237935
Depends on r237932
"Fixed intermittent failures in TestGdbRemote*/TestLldbGdbServer"
Test Plan:
Ran dosep 100x, no failures in these tests
Differential Revision: http://reviews.llvm.org/D9892
llvm-svn: 237933
test/tools/lldb-server/commandline/Test* were actually executing in
their parent directory. This looks fine at first because they aren't
compiling an inferior executable.
Unfortunately, they still call "make clean" during their cleanup,
which is likely causing all kinds of havok in tests running in the
parent directory
Differential Revision: http://reviews.llvm.org/D9869
llvm-svn: 237932
That way, if the test gets killed (by a dosep timeout) we get to see the session
trace
Test Plan:
Run dotest.py
Kill it while it's running, check the session dir for Test* files
Differential Revision: http://reviews.llvm.org/D9845
llvm-svn: 237926
If an expected timeout test times out, touch
<session-dir>/ExpectedTimeout-<test-name>
If an expected timeout test passes, touch
<session-dir>/UnexpectedCompletion-<test-name>
Differential Revision: http://reviews.llvm.org/D9843
llvm-svn: 237925
This ensures that all spawned dotest instances store their traces
in the same location.
Test Plan:
run dosep.py with and without a -s option for dotest
cd lldb/test
./dosep.py
./dosep.py -o '-s /tmp/traces'
Differential Revision: http://reviews.llvm.org/D9839
llvm-svn: 237923
ModuleSpecs::FindMatchingModuleSpec looks for matching filenames but when
looking for the dSYM we should only be looking for a matching architecture and
and UUID. Jason pointed out this mistake in http://reviews.llvm.org/D9174 when
this function was incorrectly converted to not be Mac specific.
Test Plan:
Running LLDB on test/lang/c/shared_lib_stripped_symbols/a.out in a debugger I've
verified LocateDSYMInVincinityOfExecutable correctly locates the matching dSYM.
Differential Revision: http://reviews.llvm.org/D9896
llvm-svn: 237907
This is neccessary for evaluating expressions with float/double return
value and for displaying float/double return values in case of a thread
step out.
Differential revision: http://reviews.llvm.org/D9907
llvm-svn: 237900
Summary:
Previously, NPL tried to reinject SIGSTOP into the inferior in an attempt to get the process to
start in the group-stop state. This was:
a) wrong (reinjection should be controlled by "process handle" lldb setting)
b) racy (it should use Resume for transparent resuming instead of RequestResume)
c) broken (llgs crashed on inferior SIGSTOP)
With this change, SIGSTOP is handled just like any other signal delivered to the inferior: we
stop all threads and report signal reception to lldb. SIGSTOP reinjection does not behave the
same way as it would outside the debugger, but simulating this is a hard problem and is not
normally necessary.
Test Plan: I have added a test which verifies we get SIGSTOP reports and we do not crash.
Reviewers: ovyalov, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9852
llvm-svn: 237880
breakpoint only if the process it was for is still alive. We need to always remove this because
it has a pointer to the old loader, and if we ever hit it we will crash. I also put in a sanity
check in the callback function to make sure we don't invoke it if the process is wrong.
<rdar://problem/21006189>
llvm-svn: 237866
Summary: It should default to working-dir/src-filename if dst is not specified.
Reviewers: clayborg, flackr
Reviewed By: flackr
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9890
llvm-svn: 237831
Summary:
The test in TestPlatformCommand which runs "platform process list" has
been timing out for Android when running running dosep.py with
LLDB_TEST_THREADS=8. This patch increases the packet timeout to a large
value of 1min to accommodate the long time required for a response for
the qfProcessInfo packet on Android.
Test Plan: LLDB_TEST_THREADS=8 ./dosep.py on Android.
Reviewers: chaoren
Reviewed By: chaoren
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9866
llvm-svn: 237752
It turns out, child values also need similar provisions
This patch simplifies things a bit allowing ValueObject subclasses to just declare whether they can accept an invalid context at update time, and letting the update machinery in the EvaluationPoint to the rest
Also, this lets ValueObjectChild proclaim that its parent chooses whether such blank-slate updates are possible
llvm-svn: 237714
dotest will select clang-3.5 by default and fall back on clang/gcc
dotest will look for the lldb executable in the typical cmake
output locations:
{lldb}/../../../build/bin (next to llvm directory)
{lldb}/../../../build/host/bin (next to llvm directory)
{lldb}/../build/bin (next to lldb directory)
{lldb}/../build/host/bin (next to lldb directory)
llvm-svn: 237632
The lldb executable was referenced through the code by 7 different
(effectively) global variables.
global lldbExecutablePath
global lldbExecutable
os.environ['LLDB_EXEC']
os.environ['LLDB_TEST']
dotest.lldbExec
dotest.lldbHere
lldbtest.lldbExec
This change uses one global variable lldbtest_config.lldbExec to
replace them all.
Differential Revision: http://reviews.llvm.org/D9817
llvm-svn: 237600
This patch initially was committed in r237460 but later it was reverted (r237479) due to 4 new failures:
* TestExitDuringStep.py
* TestNumThreads.py
* TestThreadExit.py
* TestThreadStates.py
This patch also fixes these tests.
llvm-svn: 237566
And they also do not have a thread/frame attached to them
That makes dynamic and synthetic values attached to them impossible to update - which, among other things, makes it impossible to properly display persistent variables of types that could have such dynamic/persistent values
Fix this by making it so that a ValueObject can control its constantness (hint: dynamic and synthetic values cannot be constant) and whether it wants to let itself be updated when an invalid thread is around
llvm-svn: 237504
In http://reviews.llvm.org/D9754 I enabled the mangled symbol name lookup
workaround used to find global and anonymous namespace symbols in linux binaries
for all platforms, however we should still only check for these symbols when
processing Linux or FreeBSD binaries where they are relevant. This patch makes
this change.
Test Plan: The tests from the original revision still pass:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9782
llvm-svn: 237467
When compiling programs for the test suite we currently choose which stdlib to
use based on the host platform, but should be basing this on the target
platform.
Test Plan: ./dotest.py $DOTEST_OPTS -t -p TestThreadExit.py
This test previously failed mac->linux most of the time due to using the mac
host's atomic declaration.
Differential Revision: http://reviews.llvm.org/D9797
llvm-svn: 237466
Summary:
This option forces to only set a source line breakpoint when there is an exact-match
This patch includes the following commits:
# Add the -m/--exact-match option in "breakpoint set" command
## Add exact_match arg in BreakpointResolverFileLine ctor
## Add m_exact_match field in BreakpointResolverFileLine
## Add exact_match arg in BreakpointResolverFileRegex ctor
## Add m_exact_match field in BreakpointResolverFileRegex
## Add exact_match arg in Target::CreateSourceRegexBreakpoint
## Add exact_match arg in Target::CreateBreakpoint
## Add -m/--exact-match option in "breakpoint set" command
# Add target.exact-match option to skip BP if source line doesn't match
## Add target.exact-match global option
## Add Target::GetExactMatch
## Refactor Target::CreateSourceRegexBreakpoint to accept LazyBool exact_match (was bool)
## Refactor Target::CreateBreakpoint to accept LazyBool exact_match (was bool)
# Add target.exact-match test in SettingsCommandTestCase
# Add BreakpointOptionsTestCase tests to test --skip-prologue/--exact-match options
# Fix a few typos in lldbutil.check_breakpoint_result func
# Rename --exact-match/m_exact_match/exact_match/GetExactMatch to --move-to-nearest-code/m_move_to_nearest_code/move_to_nearest_code/GetMoveToNearestCode
# Add exact_match field in BreakpointResolverFileLine::GetDescription and BreakpointResolverFileRegex::GetDescription, for example:
was:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
now:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
Test Plan:
./dotest.py -v --executable $BUILDDIR/bin/lldb functionalities/breakpoint/
./dotest.py -v --executable $BUILDDIR/bin/lldb settings/
./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/breakpoint/
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9273
llvm-svn: 237460
Summary:
There was an issue in NPL, where we attempted removal of temporary breakpoints (used to implement
software single stepping), while some threads of the process were running. This is a problem
since we currently always use the main thread's ID in the removal ptrace call. Therefore, if the
main thread was still running, the ptrace call would fail, and the software breakpoint would
remain, causing all kinds of problems. This change removes the breakpoints after all threads have
stopped. This fixes TestExitDuringStep on Android arm and can also potentially help in other
situations, as previously the breakpoint would not get removed if the thread stopped for another
reason.
Test Plan: TestExitDuringStep passes, other tests remain unchanged.
Reviewers: tberghammer
Subscribers: tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D9792
llvm-svn: 237448
Summary:
This is the same issue as we had in D9145 for thread creation. Going through the full
ThreadDidStop/RequestResume cycle can cause a deferred notification to fire, which is not correct
when we are ignoring an event and resuming the thread. In this case it doesn't matter much since
the thread will die after that anyway, but for correctness, we should do the same thing here.
Also treating the SIGTRAP case the same way.
Test Plan: Tests continue to pass.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9696
llvm-svn: 237445
TestPluginCommands.py attempts to build a library which links against the host
built lldb library. This will only work if the remote is compatible with
binaries produced by the host.
Test Plan:
./dotest.py $DOTEST_OPTS -v -t -p TestPluginCommands.py
Test is skipped if remote platform is incompatible with host platform (i.e. mac
-> linux).
Differential Revision: http://reviews.llvm.org/D9770
llvm-svn: 237444
Aidan Dodds