case. This test case style attempts to shed all
of the boilerplate that is required for test
cases, and let 80% of test cases use a much terser
syntax.
Inline testcases have much simplified python files
(the corresponding .py file should contain two
lines of code) and require no Makefile, because the
Makefile is generated automatically. Breakpoints
are set automatically and the indicated breakpoint
actions (specified after a magic //% comment) are
executed when the breakpoint is hit.
All other testcases are unaffected.
One thing I'm not really happy with yet is the way
multiple actions for the same line are specified.
I'm going to use lang/c/struct_types as a guinea
pig to develop this further.
llvm-svn: 219984
The main issue was if you didn't specify all three (stdin/out/err), you would get file actions added to the launch that would always use the pseudo terminal. This is now fixed.
Also fixed the test suite test that handles IO to test redirecting things individually and all together and in other combinations to make sure we don't regress.
<rdar://problem/18638226>
llvm-svn: 219711
The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.
llvm.org/pr21136
llvm-svn: 219701
This addresses this bug:
http://www.llvm.org/bugs/show_bug.cgi?id=21267
Which has been broken since svn r215256 on Aug 8 2014.
DO NOT REVERT THIS COMMIT EVEN IF IT CREATES TEST FAILURES.
The test failures are a result of accumulation of hidden failures
that were masked by the bug this change fixes. Most of our test
runners as part of build testing rely on dotest.py returning non-zero to indicate
some kind of errant test run. Thus, we have been flying blind
since Aug 8 2014.
llvm-svn: 219689
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value
The rationale for doing things this way is twofold:
- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature
Comes with a test case
llvm-svn: 219330
The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.
llvm.org/pr21136
llvm-svn: 219328
the default search method is "always" as of r218405.
For the purposes of this test, set it back to "headers"
to confirm that the file+line breakpoint doesn't work,
then verify that it does work with "always". Leave it
in "always" setting.
<rdar://problem/18564244>
llvm-svn: 219251
that the function we were calling would continue to sleep
for the requested time even if it was interrupted. That is
not true of std::this_thread::sleep_for, at least not on OS X.
Fix the test case so that if it wakes up early, it goes back
to sleep till the time is actually greater than the end point.
<rdar://problem/18523742>
llvm-svn: 219234
This change does the following:
* Remove test/c++/...
* Add gtest.
* Add gtest/unittest directory for unittesting individual classes.
* Add an initial Plugins/Process?linux/ThreadStateCoordinatorTest.cpp.
- currently failing a test (intentional).
- added a bare-bones ThreadStateCoordinator.cpp to Plugins/Process/Linux,
more soon. Just enough to prove out running gtest on Ubuntu and MacOSX.
* Added recursive make machinery so that doing a 'make' in gtest/ is
sufficient to kick off the existing test several directories down.
- Caveat - I currently short circuit from gtest/unittest/Makefile directly to
the one and only gtest/unittest/Plugins/Process/Linux directory. We'll need
to add the intervening layers. I haven't done this yet since to fix the
Xcode test failure correspondence, I may need to add a python layer which
might just handle the directory crawling.
* Added an Xcode project to the lldb workspace for gtest.
- Runs the recursive make system in gtest/Makefile.
- Default target is 'test'. test and clean are supported.
- Currently does not support test failure file/line correspondence.
Requires a bit of text transformation to hook that up.
llvm-svn: 218460
Makes use of LLVM gtest support. This does *not* run as part of
the lldb test suite.
I'm using it to start testing some components that
I'll be adding to the inner guts of NativeThreadLinux to more
maintainably handle thread states and deferred thread state notification.
Runs with default Makefile target "test" using gmake within a given
test directory (currently only test/c++/native_process/thread_state_coordinator).
The Makefile.rules currently assume it is using the LLVM gtest. It works on
a canonical MacOSX dir structture (i.e. lldb, lldb/llvm, lldb/llvm/tools/clang).
It also works on Ubuntu assuming the standard dir layout of llvm, llvm/tools/clang,
llvm/tools/lldb. In this case, it expects a directory called build-debug parallel
to the llvm source dir. All directory assumptions can be overridden with
environment variables. See test/c++/make/Makefile.rules for details.
We'll want to make this smarter in the future, particularly around finding the LLVM build
output dir.
llvm-svn: 218422
Sean Callanan