SBProcess uses 2 mutexex; RunLock and APILock. Apart from 2 places, RunLock
is locked before API lock. I have fixed the 2 places where order was different.
I observed a deadlock due to this different order in lldb-mi once. Although
lldb-mi command and event thread dont run at the same time now. So it can not deadlock
there but can still be problem for some other clients.
Pre-approved by Greg in http://lists.cs.uiuc.edu/pipermail/lldb-dev/2015-February/006509.html
llvm-svn: 228844
Following changes are done.
Add missing headers.
Replace _snprintf with snprintf. It is already changed to _snprintf for MSVC.
Add a file in the build for autoconf.
Call DynamicLoaderWindows::Terminate and DynamicLoaderWindows::Initialize only for MSVC build.
Reviewed in http://reviews.llvm.org/D7536.
llvm-svn: 228822
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
Because types are not reliably protected against the death of their owners, having ValueObjects lurking around like that past the useful lifetime of their owner processes is a potential source of crashes
That is - in itself - worth fixing at some point, but for this case, watchpoints holding on to old values don't offer enough value to make the larger fix worth
Fixes rdar://19788756
llvm-svn: 228777
- you have a type that contains a typedef to a VectorType or an ExtVectorType
- that type is returned from an ARM function that LLDB steps over so we try to figure out the return type
- we try to determine if the type is a homogeneous aggregate type and we crash
We get not using getAs() when we should have been and using llvm::cast caused an assertion crash when the typedef type didn't return a valid VectorType or ExtVectorType.
<rdar://problem/19646550>
llvm-svn: 228771
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
This file MICmnStreamStdinLinux.cpp is wrongly added in the windows build.
It has no use there. CMakeList.txt for lldb-mi needs to be re-factored to
include the right file for each build. This is quick fix to un-break the build.
llvm-svn: 228714
Summary:
I don't know if there is a better way for the change in source/Host/freebsd/ThisThread.cpp
Reviewers: emaste
Subscribers: hansw, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D7441
llvm-svn: 228710
Summary:
One of the problem is reported here.
http://llvm.org/bugs/show_bug.cgi?id=22411
A fix was committed for this problem that works only for OSX. This revision
extends that fix to other system. The select system call has some limitation with
multi-threaded application which have been addresses here.
LLDB-mi exits if quit command is given but needs an extra retur if -gdb-exit is
given. That issue has also been addressed.
Reviewers: ki.stfu, emaste
Reviewed By: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7529
llvm-svn: 228709
The problem occurred when we had incorrect address ranges in the debug map that included the padding between functions causing the end address of a line table entry to fall into an inlinked (next function) address range.
<rdar://problem/19721144>
llvm-svn: 228707
This test case was checking for a specific stop reason which is different on
Linux. This caused the test to fail. It now only checks for stoppped. Also added
some more steps to run to main so that we dont pass when application has run to
completion.
llvm-svn: 228584
Previously the offset field showed the offset from the section base.
I have fixed it so that first disassembled instruction has offset of 0.
Also made a little modification in the test case to match the output coming
form the lldb-mi.
llvm-svn: 228577
The test case were failing becuase my test compiler was gcc. The generated
code behaved a bit differently to the how the test expected. Adjusted a few
lines so that it works on both gcc and clang.
llvm-svn: 228576
Summary:
When debugging two targets concurrently, the pseude terminal master fd from the first one would
leak into the second. This fixes the problem by setting O_CLOEXEC on the master fd. Test
included.
Reviewers: clayborg, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7466
llvm-svn: 228570
For some time, eclipse (CDT) uses full path of the file in break-insert command
when putting breakpoint on a source line. On windows, a typical command looks
like the following.
56-break-insert -f F:\\work\\ws\\test\\main.c:49
Current implementation in lldb-mi have problem in 2 ways.
1. It was assuming that there will be only one : in the path which is wrong if full
path is supplied.
2. CDT sends out path with double backslashes in windows which gives error on
resolution.
Fixed the : issue in lldb-mi. Changed FileSpec::Normalize to make sure that it
handles the path with \\ correctly. Added test cases to check for full path in
both lldb-mi and lldb. Also added a test case to check SBFileSpec with double
slashes.
llvm-svn: 228538
only execute thumb instructions, force the arch triple string to
be "thumbv..." instead of "armv..." so we do the right thing by
default when disassembling arbitrary chunks of code.
<rdar://problem/15126397>
llvm-svn: 228486
If you do, the test runner will fail immediately with the error:
close_fds is not supported on Windows platforms if you redirect
stdin/stdout/stderr.
llvm-svn: 228472
Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.
This allows processes using the API to pump stdin into a remote
inferior process.
It fixes a hang in TestProcessIO.py when running against a remote
target.
llvm-svn: 228419
Summary:
This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s").
See explanation below:
```
Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream)
{
...
if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ())
{
...
}
else
{
...
if (m_process_sp)
error = m_process_sp->Launch (launch_info);
}
if (error.Success())
{
if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false)
{
....
}
-- missing event if eLaunchFlagStopAtEntry is set --
m_process_sp->RestoreProcessEvents ();
}
...
return error
```
Also this patch contains tests and you can check how it works.
Reviewers: zturner, clayborg, abidh
Reviewed By: clayborg
Subscribers: clayborg, abidh, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D7273
llvm-svn: 228417
Summary:
This fixes test_with_dsym_and_run_command and test_with_dwarf_and_run_commands tests after r227285: "SBThread::GetDescription should use the Thread format instead of making up"
log:
```
======================================================================
FAIL: test_with_dsym_and_run_command (TestConvenienceVariables.ConvenienceVariablesCase)
Test convenience variables lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 456, in wrapper
return func(self, *args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 612, in wrapper
func(*args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/embedded_interpreter/TestConvenienceVariables.py", line 18, in test_with_dsym_and_run_command
self.convenience_variables()
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/embedded_interpreter/TestConvenienceVariables.py", line 83, in convenience_variables
patterns = ['SBThread: tid = 0x[0-9a-f]+'])
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 2091, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : 'print lldb.thread
thread #1: tid = 0x80d885, 0x0000000100000f4d a.out`main(argc=1, argv=0x00007fff5fbff078) + 29 at main.c:4, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
' matches expected result
Config=x86_64-clang
======================================================================
FAIL: test_with_dwarf_and_run_commands (TestConvenienceVariables.ConvenienceVariablesCase)
Test convenience variables lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 473, in wrapper
return func(self, *args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 641, in wrapper
func(*args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 612, in wrapper
func(*args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 537, in wrapper
func(*args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 537, in wrapper
func(*args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/embedded_interpreter/TestConvenienceVariables.py", line 28, in test_with_dwarf_and_run_commands
self.convenience_variables()
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/embedded_interpreter/TestConvenienceVariables.py", line 83, in convenience_variables
patterns = ['SBThread: tid = 0x[0-9a-f]+'])
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 2091, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : 'print lldb.thread
thread #1: tid = 0x80d8d3, 0x0000000100000f4d a.out`main(argc=1, argv=0x00007fff5fbff078) + 29 at main.c:4, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
' matches expected result
Config=x86_64-clang
```
Reviewers: zturner, jingham, abidh, clayborg
Subscribers: abidh, lldb-commits, jingham, clayborg, zturner
Differential Revision: http://reviews.llvm.org/D7464
llvm-svn: 228415
Summary:
These changes include:
* Fix -var-create to be able use current frame '*' (MI)
* Fix print-values option in -var-update (MI)
* Fix 'variable doesn't exist' error in -var-show-attributes (MI)
* Mark print-values option as 'handled-by-cmd' in -var-update (MI)
* Fix SBValue::GetValueDidChange if value was changed
* Fix lldb-mi: -data-evaluate-expression shows undef vars. Before this fix -data-evaluate-expression perceives undefined variables as strings:
```
(gdb)
-data-evaluate-expression undef
^done,value="undef"
```
* Minor fix: -data-evaluate-expression uses IsUnknownValue()
* Enable MiEvaluateTestCase test
All test pass on OS X.
Reviewers: abidh, clayborg
Subscribers: lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D7463
llvm-svn: 228414
Summary:
These changes include:
* Add eVariableInfoFormat argument for MIResponseFormVariableInfo{,2,3} and GetVariableInfo{,2} functions
* Fix -stack-list-locals and -stack-list-arguments: they ingored print-values
* Enable MiStackTestCase tests for -stack-list-xxx commands
All test pass on OS X.
Reviewers: abidh, clayborg
Reviewed By: abidh
Subscribers: lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D7462
llvm-svn: 228412
Summary:
* Fix -data-list-register-names command: previously it ignored regno arguments and always showed all registers
* Add 'size' field to -data-disassemble command: now we are able to get an instruction's size
* Minor fix in -data-list-register-value: fix comments/code style
* Enable all tests in MiDataTestCase
* Fix the GetRegister function that gets an register by its index
These changes were tested on OS X; all MiDataTestCase tests were passed.
Reviewers: clayborg, abidh
Reviewed By: clayborg, abidh
Subscribers: clayborg, abidh, lldb-commits
Differential Revision: http://reviews.llvm.org/D7442
llvm-svn: 228393
Summary:
After closing all the leaked file descriptors to the inferior tty, the following problem occured:
- when stdin, stdout and stderr are redirected, there are no slave descriptors open (which is good)
- lldb has a reader thread, which attempts to read from the master end of the tty
- this thread receives an EOF
- in response, it closes it's master end
- as this is the last open file descriptor for the master end, this deletes the tty and sends
SIGHUP to the inferior (this is bad)
I fix this problem by making sure the master end remains open for the duration of the inferior
process by storing a copy of the file descriptor in ProcessMonitor. I create a copy to avoid
ownership issues with the reading thread.
Reviewers: ovyalov, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7440
llvm-svn: 228391
This command is not implemented yet. Giving error gives chance to clients to
handle it properly instead of falsely assuming the lldb-mi is supporting it.
llvm-svn: 228389
* Fix cmake script for android x86
* Reorder includes to avoid collision between system macros and local
variables in clang framework
Differential Revision: http://reviews.llvm.org/D7435
llvm-svn: 228388
* Set the state of the process into running/stepping on continue/step operations
* Add mutex to use transactions in Thread State Coordinator
** It is required because the events from two Signal Handler or form a Signal handler and a Resume request shouldn't overlap
* Send Stop Replay Packet only when the state of the process changed
Differential Revision: http://reviews.llvm.org/D7374
llvm-svn: 228387
This also hooks up the new C++14 language constant to be treated
the same as the other C++ language constants.
Differential Revision: http://reviews.llvm.org/D7429
llvm-svn: 228386
and/or one or more addresses (with -a) and until will stop at the first one of thesepoints it hits,
or on exit from the function if you leave the function before hitting any of these stop points.
<rdar://problem/12438270>
llvm-svn: 228370
Summary:
This commit adds a new open flag File::eOpenOptionCloseOnExec (i.e., O_CLOEXEC), and adds it to
the list of flags when opening log files (#ifndef windows). A regression test is included.
Reviewers: vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7412
llvm-svn: 228310
This patch includes following changes:
Fix comments and code style
Add new tests for many commands
Improve existing tests
Merge MiProgramArgsTestCase and MiExecTestCase
Improve runCmd of MiTestCaseBase: add exactly option
Improve test example (make it more complicated)
Patch from ki.stfu. I xfailed some tests on Linux and also
added an empty command after -gdb-exit as it blocks without
it.
Patch was reviewed in http://reviews.llvm.org/D7410.
llvm-svn: 228286
Summary:
Mac-only tests were leaving .d.$$$$ dependency files left in the test tree. This happened
because:
1) "make clean" was invoked although no tests in the folder were run
2) The Makefile had main.d as a dependency, which meant it tried to compile the source file (to extract
dependencies).
3) The compile failed (does not compile on linux) and left behind a main.d.$$$$ temporary file.
4) "make clean" tried to clean up these temporary files, but the expansion $(wildcard *.d.[0-9]*)
was performed before the temporary file was created, so this file was not caught.
I fix this by giving all the temporary files deterministic names, which makes it easier to clean
them up afterwards. I also make the rules for generating the dependency files more robust and
less likely to leak files in the first place.
Reviewers: vharron, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7406
llvm-svn: 228285
Summary:
This adds the register plumbing, as well as register reading in FreeBSD core
dumps. Further work on the POSIX/FreeBSD ProcessMonitor is required in order to
support ptrace access to these registers.
Reviewers: tfiala, emaste
Reviewed By: emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D7039
llvm-svn: 228278
Now we make sure to update our DWARFCompileUnit -> lldb_private::CompileUnit user data when it isn't set to ensure quick transitions between the two.
<rdar://problem/18371367>
llvm-svn: 228264
Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups.
<rdar://problem/19716267>
llvm-svn: 228261
redirecting output to a path that will work well on host or target.
copying file from output location to location on local host that
test will read from
llvm-svn: 228217
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
The member m_nTimes is used in rest of lldb-mi to represent hit count.
In one place, it was assigned a wrong value (number of locations). This
resulted in lldb-mi showing a hit count of variable 1 when it was created.
Committed as obvious.
llvm-svn: 228150
Summary: This reduces the bloat in the source tree and makes the tests more consistent.
Reviewers: vharron, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7373
llvm-svn: 228134
Summary:
Both LLDB and LLGS are leaking file descriptors into the debugged process. This plugs the leak by
closing the unneeded descriptors. In one case I use O_CLOEXEC, which I hope is supported on
relevant platforms. I also added a regression test and plugged a fd leak in dosep.py.
Reviewers: vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7372
llvm-svn: 228130
lldb-mi has 3 threads.
1. One that waits for user intput.
2. Another waits for 1st thread to get input command.
3. Waits for events from lldb.
2 & 3 needs to be synchronized so that they don't end up
doing things at same time. For example, while "break insert" is
processing, we can get a breakpoint event. Depending on where we
are in "break-insert", it can have different behavior. In some
cases, it can cause breakpoint to be deleted too. I have added a
mutex so that command processing and event processing are done
exclusively and they are not running at the same time.
In longer term, I think thread 2 & 3 should be merged to be only
one thread which can wait on command or events.
Reviewed in http://reviews.llvm.org/D7371.
llvm-svn: 228128
number of bytes to write into the inferior process, the "default byte size" will be 1.
In that case, we want to copy the entire file into memory. The code was looking for
a default byte size of 0 to indicate that the user had not provided a specific # of
bytes to copy; adjust that to 1 to match the actual default value.
<rdar://problem/18074973>
llvm-svn: 228067
Summary:
The Android dynamic linker reports only the basename of each SO entry, so for
the above check to be successful, we need to compare it to the basename of the
main executable.
This also has a nasty side-effect when working with older version of
Android (verified on platform version 16), and debugging PIE
executables: the dynamic linker has a bug and reports the load address
of the main executable (which is a shared object, because PIE) to be 0.
We then try to update the list of loaded sections for all shared
objects, including the main executable, and set the load address to 0,
which breaks everything that relies on resolving addresses in the main
executable (breakpoints, stepping, etc). This commit also fixes that broken
behavior when debugging on older Androids. This bug doesn't happen on newer
Android versions (verified for Android L).
Test Plan: Run test suite on linux.
Reviewers: clayborg, tfiala, richard.mitton
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7188
llvm-svn: 228057
On windows, signal handler is reset to default once a signal is received.
This causes doing ctrl-c twice on console (or pressing suspend button twice
in eclipse ide which uses SIGINT to stop the debuggee) to crash lldb-mi on
windows. Although there is very tiny window (after signal handler is called
and before we restore the handler) where default handler will be in place.
But this is hardly a problem in practice as IDEs generally disable their suspend
button once it has been presses.
llvm-svn: 227964
This patch fixes execution of CLI commands in MI mode. The CLI commands are
executed using "-interpreter-exec" command. The bug was in the
CMICmnLLDBDebugSessionInfo class which contained the following members:
SBProcess, SBTarget, SBDebugger and SBListener, but CLI commands don't affect
them and they aren't updated. Therefore some members can contain incorrect
(or obsolete) reference and it can cause an error. My patch removes these
members and uses getters that provides the updated instance every time it is used.
Patch from Ilia K ki.stfu@gmail.com. Approved by Greg.
llvm-svn: 227958
This was causing code that opened multiple targets to try and get a path to debugserver from the GDB remote communication class, and it would get the LLDB path and some instances would return empty strings and it would cause debugserver to not be found.
<rdar://problem/18756927>
llvm-svn: 227935
Remove implicit stop action on $vCont package for threads where no
explicit action or default action specified based on the specification
(they have to stay in there original state).
llvm-svn: 227933
LLGS debugging is outputting different thread stop reasons than
local linux debugging. The stop reasons are reasonable so I've left
left them alone. Might update them to match darwin in the future.
llvm-svn: 227920
NativeProcessLinux::MonitorSignal was automatically resuming threads
that stopped due to a signal. This is inconsistent with the
behavior of lldb and gdb. This change removes the automatic resume.
Fixes
TestSendSignal.py
TestSignalsAPI.py
if PLATFORM_LINUX_FORCE_LLGS_LOCAL is in the environment vars.
llvm-svn: 227918
Note this code path should not happen - it implies a bug in another part of
the code. For the thread to receive the stop signal as it is handled, the
and for it to already have a stop reason, it implies the kernel was able to
tell the thread that it stopped while it was stopped. More likely this
seems to indicate a bug where an actual thread start was not getting correctly
logged. If it does get hit, we'll want to understand the sequence to figure
out if it is truly legitimate or if it implies another bug.
llvm-svn: 227916
It looks like Shawn's fix addresses what the initial hijacking was trying
to accomplish per conversations with Greg and Jim. The hijacking was
causing several tests to hang (#61, #62, #63, #64, #67, possibly more).
These tests now just fail rather than hang with this modification.
llvm-svn: 227914
* When the thread state coordinator is told to skip sending a stop request
for a running thread that is ignored (e.g. the thread that steps in a
step operation is technically running and should not have a stop sent
to it, since it will stop of its own accord per the kernel step operation),
ensure the deferred signal notification logic still waits for the
skipped thread. (i.e. we want to defer the notification until the
stepping thread is indeed stopped, we just don't want to send it a tgkill).
* Add ThreadStateCoordinator::RequestResumeAsNeeded(). This variant of the
RequestResume() method does not call the error function when the thread
is already running. Instead, it just logs that the thread is already
running and skips the resume operation. This is useful for the case of
vCont;c handling, where we tell all threads that they should be running.
At the place we're calling, all we know is "we want this thread running if
it isn't already," and that's exactly what this command does.
* Formatting change (minor) in NativeThreadLinux logging.
llvm-svn: 227913
See https://github.com/tfiala/lldb/issues/75. Not fixed yet but
continuing to push this further.
Fixes:
* Resume() now skips doing deferred notifications if we're doing a
vCont;{c,C}. In this case, we're trying to start something up,
not defer a stop notification. The default thread action stop
mode pickup was triggering a stop because it had at least one
stop, which was wrong in the case of a continue. (Bug introduced
by previous change.)
* Added a variant to ThreadStateCoordinator to specify a set of
thread ids to be skipped when triggering stop notifications to
non-stopped threads on a deferred signal call. For the case of
a stepping thread, it is actually told to step (and is running)
for a brief moment, but the thread state coordinator would think
it needed to send the stepping thread a stop, which id doesn't
need to do. This facility allows me to get around that cleanly.
With this change, behavior is now reduced to something I think is
essentially a different bug:
* Doing a step into libc code from my code crashes llgs.
* Doing a next out of a function in my own code crashes llgs.
llvm-svn: 227912
Tracked down while working on https://github.com/tfiala/lldb/issues/75.
This is not a complete fix for that issue, but moves us farther along.
Fixes:
* When a thread step is requested via vCont:{s,S}, Resume() now marks
the stepping thread as (1) currently stepping and (2) does trigger
the deferred signal for the stepped thread. This fixes a bug where
we were actually triggering a deferred stop cycle here for the non-stepping
thread since the single step thread was not part of the Resume()
deferred signal mechanism. The stepping thread is also marked in
the thread state coordinator as running (via a resume callback).
* When we get the SIGTRAP signal for the step completion, we don't
do a deferred signal call - that happened during the vCont:{s,S}
processing in Resume() already. Now we just need to mark that
the stepping thread is now stopped. If this is the last thread
in the set that needs to stop, it will trigger the process/delegate
stop call that will notify lldb. Otherwise, that'll happen when
the final thead we're waiting for stops.
Misc:
* Fixed up thread stop logging to use a leading 0 (0x%PRIx32) so
we don't get log lines like 0x5 for 0x05 SIGTRAP.
llvm-svn: 227911
* Fixed bug in run loop where run loop return enum was being treated
erroneously like an int, causing the TSC event loop to terminate
prematurely.
* Added an explicit scope in NativeProcessLinux::Resume() for the
threads lock lifetime. (This was likely unnecessary but is
more explicit.)
* Fixed a bug in ThreadStateCoordinator where resume execution was
not updating the internal state about the thread assumed to be
running now. I'll add a test and upstream this in a moment.
* Added a verbose logging mechanism to event processing within
ThreadStateCoordinator. It is currently enabled when the
'log enable lldb thread' is true upon inferior launch/attach.
llvm-svn: 227909
When it runs, lldb-mi creates a log file. There is an option --noLog
to disable the creation but it does not work and you end up with log
file. This happens as log is enabled in a few places in the code
although it has been disabled by this option.
This commit tried to fix the problem in the following way.
Log file generation is disabled by default.
You can enable it by giving --log option. It is the only way to enable
it. Rest of the call have been removed.
So the code basically remove the calls that enable the log
unconditionally and changes the option --noLog to --log.
llvm-svn: 227810
Currently it was marked as mandatory for many commands. Although it
is recommended that fronends generate this argument, it is not
mandatory. GDB seems to treat it as optional too.
llvm-svn: 227798
create its own threads with 8MB additional maximum stack size.
Extra room is needed for the bookkeeping needed for this
instrumentation.
llvm-svn: 227421
for executable binaries on the local filesystem so the user doesn't
need to provide the path to the correct binary manually.
Also have lldb search for kexts/the kernel in the current working
directory in addition to all the usual places.
<rdar://problem/18126501>
llvm-svn: 227419
./dotest.py -A x86_64 -C clang -v -t -f TestImageListMultiArchitecture.test_image_list_shows_multiple_architectures
The problem was that if the platform wasn't compatible with the current file in the "target create" command, it wasn't finding a platform that was like it used to.
Also, the currently selected platform was being used upload the file _before_ the target was created which was incorrect as "target create a.out" might switch platforms if its architecture doesn't match, so I moved the uploading to happen after the target was created so we use the right platform (the one in the target, not the selected one).
llvm-svn: 227380
The change was made so we could re-use a platform if one was already created instead of creating a new one, but it would fail in the above case. To fix this, if we have a selected platform, we verify that the platform matches the current platform before we try to re-use it. We do this by asking the OptionGroupPlatform if the platform matches. If so, it returns true and we don't create a new platform, else we do.
llvm-svn: 227288
And since enough of these are doing the right thing, add a test case to verify we are doing the right thing with freeze drying ObjC object types
Fixes rdar://18092770
llvm-svn: 227282
Namely, this commit provides an actual implementation of how to retrieve the byte size in a sane way for an ObjC class, by scanning ivar offsets and byte sizes, figuring out the farthest-from-base ivar, and adding its byte size to that
Still NFC
llvm-svn: 227277
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
This test tests the equivalent of:
breakpoint set --name count
breakpoint set --selector count
breakpoint set --name isEqual:
breakpoint set --selector isEqual:
breakpoint set --name "-[MyClass(MyCategory) myCategoryFunction]"
breakpoint set --name "-[MyClass myCategoryFunction]"
breakpoint set --name "[MyClass myCategoryFunction]"
llvm-svn: 227271
This patch adds lldbmi_testcase.MiTestCaseBase class and removes
a lot of repitition in the lldb-mi test cases. Also cleans import
list and code-style.
Presented for review in http://reviews.llvm.org/D7162.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 227218
it does call, and implementing it so that we once again look up external symbols in the JIT.
Also juked the error reporting from the JIT a little bit.
This resolves:
http://llvm.org/bugs/show_bug.cgi?id=22314
llvm-svn: 227217
This was causing problems on clang 602 branches that use MemoryObjects to as the container for opcode bytes instead of a plain array of bytes. So we were asking for 3 bytes to be disassembled at address 0xffffffffffffffff which would cause an unsigned overflow and cause the MemoryObject to refuse to read anymore bytes.
llvm-svn: 227153
Without this overload, attempts to edit the value of a variable with synthetic children enabled would change the value inside the synthetic ValueObject, but not propagate the changes to the underlying storage, hence resulting in no write for any meaningful purpose
Comes with a test case, and fixes rdar://19586311
llvm-svn: 227120
This patch fixes test_launch_in_terminal test which doesn't work
in OS X since the moment as it was added in r225284. The test fails
because Target::Launch returns the following error: "the darwin-debug
executable doesn't exist at
<output_dir>/lib/python2.7/site-packages/lldb/darwin-debug'".
Patch by Ilia K
Differential Revision: http://reviews.llvm.org/D7102
llvm-svn: 227096
Ilia K <ki.stfu@gmail.com> sent this patch. He noted that it was possible for
child to be terminated after isAlive call and before we send it quit command.
In this case, sending command to it causes OSError. This patch just adds this
exception to the except list.
llvm-svn: 227086
This patch fixes TestRegisters on Linux with LLGS
Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish
lldb internal registers (e.g.: DR0-DR7) during register counting.
Update GDBRemoteCommunicationServer to skip lldb internal registers on
read/write register and on discover register.
Submitted for Tamas Berghammer
llvm-svn: 226959
Other platforms may benefit from something similar if issues arise. The
libedit library doesn't explicitly initialize the curses termcap library,
which it gets away with until TERM is set to VT100 where it stumbles over
an implementation assumption that may not exist on other platforms.
<rdar://problem/17581929>
llvm-svn: 226891
i386/x86_64 functions. The stack size was being multiplied by the
pointer size incorrectly. The register permutation placeholders
(UNWIND_X86_REG_NONE) were decrementing the stack offset of the
saved registers when it should not have been.
<rdar://problem/19570035>
llvm-svn: 226889
paths we get from dladdr to have "//" in it internally, and while that is
formally correct it is just asking for somebody to misparse it...
llvm-svn: 226886
On Windows we copy python27(_d).dll to the bin directory. We do
this by looking at the PYTHON_LIBRARY specified by the user, which
is something like C:\foo\python27_d.lib, and replacing ".lib" with
".dll". But ".lib" as a regex will also match "flib", etc. So
make this a literal . instead of a wildcard .
llvm-svn: 226858
This matches the behavior of the default constructor, so is
technically more correct.
Patch by Chaoren Lin
Differential Revision: http://reviews.llvm.org/D7113
llvm-svn: 226851
When you create a target, it tries to look for the platform's list
of supported architectures for a match. The match it finds can
contain specific triples, like i386-pc-windows-msvc. Later, we
overwrite this value with the most generic triple that can apply
to any platform with COFF support, causing some of the fields of
the triple to get overwritten.
This patch changes the behavior to only merge in values from the COFF
triple if the fields of the matching triple were unknown/unspecified
to begin with.
This fixes load address resolution on Windows, since it enables the
DynamicLoaderWindows to be used instead of DynamicLoaderStatic.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D7120
llvm-svn: 226849
buffer and to add a nul terminator byte, was incorrectly resizing
its buffer so the nul terminator was not included.
Problem found by clang ASAN instrumentation when using an
expression prefix file which was read via this mechanism.
<rdar://problem/19556459>
llvm-svn: 226753
inferring the function signature. This works well where the ABI doesn't
distinguish between variadic and fixed argument lists, but on arm64 the
calling conventions differ. The default assumption works for fixed argument
lists, but variadic functions require explicit prototypes to be called.
By far the most common case where this is an issue is when attempting to use
printf(). This change augments the default expression prefix to include a
working variadic prototype for the function.
<rdar://problem/19024779>
llvm-svn: 226744
The reason why one mechanism is so much faster than the other (as in, ~10 seconds vs. ~1 minute) is quite baffling to me at the moment, but these are not process handling tests, so do what's faster
llvm-svn: 226730
Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
Since REG_ENHANCED is available on MacOSX, this allow the use of \d (digits) \b (word boundaries) and much more without affecting other systems.
<rdar://problem/12082562>
llvm-svn: 226704
This reverts commit r226679. For some reason it was
not generating the same behavior as manually specifying
the include dir, library path, and exe path, and it was
causing the test suite to fail to run.
llvm-svn: 226683
CMake FindPythonLibs will look for multiple versions of Python
including both debug and release, and build up a list such as
(debug <debugpath> optimized <optimizedpath>). This confuses
the logic we have in CMake to copy the correct python dll to
the output directory so that it need not be in your system's PATH.
To alleviate this, we manually split this list and extract out
the debug and release versions of the python library, and copy
only the correct one to the output directory.
llvm-svn: 226679
Most of the time, we can use context information just fine to choose a language (i.e. the language of the frame that the root object was defined in, if any); but in some cases, synthetic children may be fabricated as root frame-less entities, and then we wouldn't know any better
This patch allows (internal) synthetic child providers to set a display language on the children they generate, should they so choose
llvm-svn: 226634
introduced subtle bugs in two places in
RegisterContextLLDB::GetFullUnwindPlanForFrame where
it specifically wanted to get an eh_frame unwind plan
and was using "Get CallSite UnwindPlan" as synonymous
with that. But now we have two different types of
unwind plan that can be returned in that case, and
compact unwind won't behaves as needed.
<rdar://problem/19528559>
llvm-svn: 226631
We were referring to hardcoded paths /bin/ls and /bin/cat. For
the purposes of this test, the actual value it's set to doesn't
matter, and it might as well be a non-existent path. All that
matters is that the before and after values have to match, and
that trailing whitespace is stripped. On Windows FileSpec
(correctly) converts /bin/ls to D:\bin\ls though, so the before
and after values won't match. So this patch just correctly builds
up a valid path in a platform-agnostic manner, and verifies that
it matches before and after the set.
llvm-svn: 226625
At some point we will need to either provide a pexpect equivalent
on Windows, or provide some other method of doing out-of-process
tests.
Even with a pexpect replacement, it may be worth re-evaluating
some of these tests to see if they would be better served as
in-process tests. The larger issue of coming up with a pexpect
replacement on Windows is tracked in http://llvm.org/pr22274.
llvm-svn: 226614
lldb::pid_t
Host::LaunchApplication (const FileSpec &app_file_spec);
This had use of a function FSPathMakeRef(const UInt8*, FSRef *, ...) that was deprecated in 10.8.
Removing this fucntion since it wasn't used and was causing warnings.
llvm-svn: 226608
This fixes file paths on Windows, as you can now write, for example,
file d:\foo\bar.txt, but does not break the case that this tokenization
logic was originally designed for, which is to allow escaping of things
like quotes and double quotes, so that all of the escapable characters
can appear in the same string together.
Reviewed by: Jim Ingham, Greg Clayton
Differential Revision: http://reviews.llvm.org/D7018
llvm-svn: 226587
so it doesn't assume that the SmallVector<char> will have
nul terminator. It did not in at least one case.
Caught by ASAN instrumentation.
llvm-svn: 226544
Include paths were switched to be user include paths, if this breaks the linux build we will need to fix the Makefiles/cmake stuff.
<rdar://problem/19198581>
llvm-svn: 226530
CommandInterpreter's execution context AFTER the process had started running
and before it initially stopped. Also fixed one test case that was implicitly
using this (and an abuse of the async mode) to accidentally succeed.
<rdar://problem/16814726>
llvm-svn: 226528
This function returns a URI of the resource that the connection is connected to. This is especially important for connections established by accepting a connection from a remote host.
Also added implementations for ConnectionMachPort, ConnectionSharedMemory,
Also fixed up some documentation in Connection::Write
Renamed ConnectionFileDescriptorPosix::SocketListen to ConnectionFileDescriptorPosix::SocketListenAndAccept
Fixed a log message in Socket.cpp
Differential Review: http://reviews.llvm.org/D7026
llvm-svn: 226362
the register state when debugging AArch32 programs (armv7
programs running on an armv8 processor). Most notably,
there is no "fpscr" register in the register context -
there is an fpsr and an fpcr.
Also fix a bug where the floating point values could not
be written in armv7 processes.
<rdar://problem/18977767>
llvm-svn: 226244
`ninja lldb` used to always run "echo -n", which on OS X results in literally
echoing "-n" to the screen. Just remove the command from add_custom_target,
then it only adds an alias and `ninja lldb` now reports "no work to do".
Other than that, no intended behavior change.
llvm-svn: 226233
This hooks up the changes necessary to set the trap flag on the
CPU and properly manage the process and thread's resume state
and private state so that the ThreadPlan does its thing.
Stepping still doesn't work as of this change, because there are
some issues with stack frames where it doesn't update the thread's
frame list correctly when it breaks inside of a function, but
I will try to fix that separately.
llvm-svn: 226221
On Windows, opening with "w" opens it as text instead of binary.
This causes translation of newline characters, so that "\n" turns
into "\r\n", which in turn leads to git detecting that the file
has changed and wanting to commit it.
llvm-svn: 226220
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
moved into the #else branch of the #if/#elif/#endif, so it wasn't getting done in the #if case anymore.
Keep the code to add the demangled name outside of the #if, and then just free the demangled_name
and set it back to NULL in the Windows case.
<rdar://problem/19479499>
llvm-svn: 226088
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
the hit count is not updated.
Also, keep the hit count for the breakpoint in the breakpoint. We were
using just the sum of the location's hit counts, but that was wrong since if a shared library is
unloaded, and the location goes away, the breakpoint hit count should not suddenly drop
by the number of hits there were on that location.
llvm-svn: 226074
The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning.
The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably.
Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands.
<rdar://problem/17751929>
<rdar://problem/16953815>
<rdar://problem/16953841>
<rdar://problem/16930173>
<rdar://problem/16879028>
llvm-svn: 226068
While there is quite a bit of potential for mishaps due to tagged pointers, and after quite some internal discussion, this seems a saner behavior given how "po" stands for "print OBJECT". The argument being that we should make at least some sensible attempt to print the thing the user passed as-if it was an object
Fixes rdar://19423124
llvm-svn: 226062
These fix various issues with path handling and disable a few tests
which use features of LLVM which are not yet supported on Windows.
llvm-svn: 226042
BUILD_SHARED_LIBS=TRUE currently isn't working for Linux x86_64
This patch fixes the link errors and also some runtime errors
Test Plan:
CC=clang CXX=clang++ cmake -GNinja -DBUILD_SHARED_LIBS=TRUE -DCMAKE_LINKER=ld.gold -DCMAKE_BUILD_TYPE=Debug ../../llvm
ninja
ninja check-lldb
llvm-svn: 226039
If stdout is not a terminal Python executes
rl_variable_bind ("enable-meta-key", "off");
This produces a warning with FreeBSD's libedit because the
enable-meta-key variable is unknown. Not an issue on Apple because
cpython commit f0ab6f9f0603 added a #ifndef __APPLE__ around the call.
See http://bugs.python.org/issue19884 for more information.
For now we just discard the warning output to get the tests working
again on FreeBSD.
llvm-svn: 226037
We now verify that the debugger's input file is a valid terminal file descriptor before allowing the "gui" command to try to run.
Xcode would crash if you typed "gui" at the command line prior to this fix.
<rdar://problem/18775851>
llvm-svn: 226027
saved/restored across a mid-function epilogue. We ignore
repeated push/pops of a register so once we saw one 'pop %rbp',
we'd ignore it the second time we saw it.
<rdar://problem/19417410>
llvm-svn: 225853
This is currently controlled by a setting:
(lldb) settings set target.process.python-os-plugin-path <path>
Or clearing it with:
(lldb) settings clear target.process.python-os-plugin-path
The process will now reload the OperatingSystem plug-in.
This was implemented by:
- adding the ability to set a notify callback for when an option value is changed
- added the ability for the process plug-in to load the operating system plug-in on the fly
- fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits
- adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user
- fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded
llvm-svn: 225831
it will do the right thing on x86 routines with a mid-function
epilogue sequence (where the unwind rules need to be reinstalled
after the epilogue has completed).
<rdar://problem/19417410>
llvm-svn: 225773
which will verify if the eh_frame instructions include details about
the prologue or not. Both clang and gcc include prologue instructions
but there's no requirement for them to do so -- and I'm sure we'll
have to interoperate with a compiler that doesn't generate prologue
info at some point.
I don't have any compilers that omit the prologue instructions so the
testing was of the "makre sure augmented unwind info is still created".
With an eh_frame without prologue, this code should reject the
augmentation scheme altogether and we should fall back to using assembly
instruction profiling.
llvm-svn: 225771
step through the complete function looking for any epilogue
instructions. If we find an epilogue sequence, re-instate
the correct unwind instructions if there is more code past
that epilogue -- this will correctly handle an x86 function
with multiple epilogues in it.
NB there is still a bug with the "eh_frame augmented"
UnwindPlans and mid-function epilogues. Looking at that next.
<rdar://problem/18863406>
llvm-svn: 225770
The terminal window will be opened under the ownership
of the real userid and it won't be able to open the
socket talking back to lldb -- the testsuite will hang
here.
The same thing probably should be done for lldb when run
on a remote system over ssh. I added a line for that
but commented it out for now because I haven't
tested it.
llvm-svn: 225748
This will allow, in a subsequent patch, the addition of a global
setting that allows the user to specify a single character that
LLDB will recognize as an escape character when processing arg
strings to accomodate differences in Windows/non-Windows path
handling.
Differential Revision: http://reviews.llvm.org/D6887
Reviewed by: Jim Ingham
llvm-svn: 225694
it more generally available.
Add checks to UnwindAssembly_x86::AugmentUnwindPlanFromCallSite() so
that it won't try to augment an UnwindPlan that already describes
the function epilogue.
Add a test case for backtracing out of _sigtramp on Darwin systems.
This could probably be adapted to test the same thing on linux/bsd but
the function names of sigtramp and kill are probably platform
specific and I'm not sure what they should be.
llvm-svn: 225578
Top of tree never regressed, but we have internal branches that we constantly merge and we need to make sure we don't regress.
<rdar://problem/19429907>
llvm-svn: 225572
This fixes an issue of running "script" commands via SBDebugger::HandleCommand(...) and SBCommandInterpreter::HandleCommand(...) deadlocking Xcode.
<rdar://problem/18075038>
llvm-svn: 225567
Summary: This will ease llgs development a bit by not requiring an lldb/lldb.py build to launch the tests. Also, we can now use LLDB_DEBUGSERVER_PATH to point to a debug server to use to run the tests. I used that to point to a ds2 build and run llgs tests against ds2.
Reviewers: clayborg, tfiala, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6554
llvm-svn: 225549
MS ABI guard variables end with @4IA, so this patch teaches the
interpreter about that. Additionally, there was an issue with
TurnGuardLoadIntoZero which was causing some guard uses of a
variable to be missed. This fixes that by calling
Instruction::replaceAllUsesWith() instead of trying to replicate
that function.
llvm-svn: 225547
Variable was being declared as signed, but treated as unsigned at
every point of use.
Patch by Dan Sinclair
Differential Revision: http://reviews.llvm.org/D6897
llvm-svn: 225540
I have been seeing a few crashes where LLDB tries to acquire a cached synthetic child by index, and crashes in the ClusterManager obtaining a shared_ptr for that ValueObject
That kind of crash most often means that I am holding on to a raw pointer to a ValueObject that was let go from the cluster
The main way that could happen is that the synthetic provider is being updated at the same time that some child is being accessed from the previous provider state
This fixes the problem by making the children be stored in a thread-safe map
Fixes rdar://18627964
llvm-svn: 225538
This new command will delete user defined regular commands, but not aliases. We still have "command unalias" to remove aliases as they are currently in different buckets. Appropriate error messages are displayed to inform the user when "command unalias" is used on removable user defined commands that points users to the "command delete" command.
Added a test to verify we can remove user defined commands and also verify that "command unalias" fails when used on a user defined command.
<rdar://problem/18248300>
llvm-svn: 225535
Summary:
The main issue that this patch is trying to address is that the current
implementation of getRerunArgs of InlineTest relies on the attribute
'using_dsym' which could be absent if the test was skipped altogether.
[That is, if both dsym and dwarf tests were skipped.]
While at it, the use of deprecated Python module 'new' is eliminated.
Test Plan: [Linux] dotest.py -p TestExprPathSynthetic
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6888
llvm-svn: 225496
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash
This is the easiest case I could think of that forces the failed update case Zachary was seeing
llvm-svn: 225463
which registers have been spilled (saved to the stack) - and
if we see that same register being saved to the stack again,
don't record that, it's something specific to this stack frame.
I found a code sequence for i386 where clang did a push %esi
and then later in the function it did movl %esi, -0x7c(%ebp)
and that second save of a scratch value overrode the original
push location.
<rdar://problem/19171178>
llvm-svn: 225431
so that we will use the UnwindPlan's rule for providing the stack
pointer BEFORE we use the trick of using the callee's CFA address
as the stack pointer. When we're in a _sigtramp frame, the CFA of
the _sigtramp stack frame is not the same as the stack pointer value
when the async interrupt occurred -- we need to use the eh_frame
rules for retrieving the correct value.
<rdar://problem/18913548>
llvm-svn: 225427
To fix this I added a new method to TestBase:
def getRerunArgs(self):
return " -f %s.%s" % (self.__class__.__name__, self._testMethodName)
The InlineTest which inherits from TestBase then overrides this function with a custom version which does the right thing.
llvm-svn: 225407
Differential Revision: http://reviews.llvm.org/D6797
lldb-gdbserver statically links all llvm dependencies. This allows
dead stripping code and reduces total binary size.
This change modifies lldb-plaform to static link llvm dependencies
like lldb-gdbserver.
llvm-svn: 225398
This was causing a race condition where DoDestroy() would acquire
the lock and then initiate a shutdown and then wait for it to
complete. But part of the shutdown involved acquiring the same
lock from a different thread. So the main thread would timeout
waiting for the shutdown to complete and return too soon.
The end result of this is that SBProcess::Kill() was broken on
Windows.
llvm-svn: 225297
A recent POSIX host thread issue where HostThreadPosix::Join() wasn't returning the thread result was responsible for this regression, yet we had no test case covering this so it wasn't discovered.
llvm-svn: 225284
Summary:
GCC emits DW_TAG_subrange_type for static member arrays, but with no
attributes. This in turn results in wrong type/value of the array when
printing with 'target variable <array var name>'. This patch fixes this
so that the array value is printed in this format:
(<element type> []) <array var name> = {}
Earlier, the array was being interpreted to be of its element type.
Note: This does not fix anything to do with 'expr' or 'p' commands.
Those commands still error out complaining about incomplete types.
Test Plan: dotest.py -p TestStaticVariables
Reviewers: emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6799
llvm-svn: 225219