This test was skipped as it used to segfault on FreeBSD. It seems
the original issue has since been fixed, so have the test run again.
llvm-svn: 201169
This could use some refinement still, but the previous behaviour of adding
-stdlib=libstc++ on FreeBSD w/ Clang is the least likely case to work.
llvm.org/pr17910
llvm-svn: 200646
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
This change addresses shutdown crashes in the python lldb module when
the script interpreter was hanging on to saved file references after
leaving a session. It also gets rid of extra references to the
stdin/stdout/stderr python file objects that are created when entering
the session.
This change also moves the bundled pyexpect 2.4 library to the front
of the python library path so that a python distribution default
pyexpect (2.3 in Ubuntu 12.04) is not picked up first.
llvm-svn: 200486
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case
Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero.
llvm-svn: 200247
The alias test "exprf x 1234" expands to "expr -f x 1234" and is
expected to fail: it ends up trying to evaluate the invalid expression
void
$__lldb_expr(void *$__lldb_arg)
{
-f x 1234;
}
On FreeBSD LLDB ends up finding a static function f() in a math library,
and thus the error produced does not include "use of undeclared
identifier 'f'".
We will report failure to parse the expression in any case, so require
only that error message.
llvm-svn: 199623
Part 1 changes PlatformLinux::CreateInstance to always create with
is_host=false; that method is only used as the plug-in creator method
associated with the remote-linux platform plugin, and should therefore
always be remote.
Part 1 patch by Steve Pucci.
Part 2: fix a test break on linux.
In test/functionalities/thread/thread_specific_break, when using gcc,
either C99 mode would need to be enabled, or the code would need to
change. I changed a couple loop variable definitions to conform
to pre-C99 to simplify testing the fix. The second issue was
the necessity to include -lpthread as a linker option in the Makefile.
Any issues with that part are due to me (Todd Fiala).
llvm-svn: 199426
control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
and re-exported symbols. I don't know if Linux has the latter, if it does, we could
probably make this a generic test. Somebody who knows how to make these gadgets on
Linux can maybe take a look...
llvm-svn: 199134
<rdar://problem/15797390>
This new test case will detect this and make sure we don't regress on global name lookups that search all DWARF for everything when we don't need to.
llvm-svn: 198982
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
test_convenience_registers_16bit_with_process_attach fails due to
pr18200. The test has a @expectedFailureFreeBSD decorator, but it
appears this does not catch a RuntimError exception raised in the test
infrastructure, so the test still reports failure. For now just skip
it.
llvm-svn: 197174
With this checkin, we use the installed clang compiler to build crashinfo.so from crashinfo.c upon every test suite execution
We also try to cleanup after ourselves, which of course will only work if the test suite does not actually crash
llvm-svn: 197106
Add an hook for the test suite into the OSX-only CrashReporter "App-specific info"
This allows the test suite to set the crash info to the name and file location of every test as the test gets executed
If the test suite crashes, the crash log will then report which test is the culprit, even when not using verbose mode
This only works on OSX, and defaults to not doing anything on other platforms, but OS/platform-specific invocations
can be devised by each individual platform
llvm-svn: 197095
This has led to many test suite failures because of copy and paste where new test cases were based off of other test cases and the "mydir" variable wasn't updated.
Now you can call your superclasses "compute_mydir()" function with "__file__" as the sole argument and the relative path will be computed for you.
llvm-svn: 196985