Commit Graph

4 Commits

Author SHA1 Message Date
Tamas Berghammer c8fd130a2c Merge dwarf and dsym tests
Currently most of the test files have a separate dwarf and a separate
dsym test with almost identical content (only the build step is
different). With adding dwo symbol file handling to the test suit it
would increase this to a 3-way duplication. The purpose of this change
is to eliminate this redundancy with generating 2 test case (one dwarf
and one dsym) for each test function specified (dwo handling will be
added at a later commit).

Main design goals:
* There should be no boilerplate code in each test file to support the
  multiple debug info in most of the tests (custom scenarios are
  acceptable in special cases) so adding a new test case is easier and
  we can't miss one of the debug info type.
* In case of a test failure, the debug symbols used during the test run
  have to be cleanly visible from the output of dotest.py to make
  debugging easier both from build bot logs and from local test runs
* Each test case should have a unique, fully qualified name so we can
  run exactly 1 test with "-f <test-case>.<test-function>" syntax
* Test output should be grouped based on test files the same way as it
  happens now (displaying dwarf/dsym results separately isn't
  preferable)

Proposed solution (main logic in lldbtest.py, rest of them are test
cases fixed up for the new style):
* Have only 1 test fuction in the test files what will run for all
  debug info separately and this test function should call just
  "self.build(...)" to build an inferior with the right debug info
* When a class is created by python (the class object, not the class
  instance), we will generate a new test method for each debug info
  format in the test class with the name "<test-function>_<debug-info>"
  and remove the original test method. This way unittest2 see multiple
  test methods (1 for each debug info, pretty much as of now) and will
  handle the test selection and the failure reporting correctly (the
  debug info will be visible from the end of the test name)
* Add new annotation @no_debug_info_test to disable the generation of
  multiple tests for each debug info format when the test don't have an
  inferior

Differential revision: http://reviews.llvm.org/D13028

llvm-svn: 248883
2015-09-30 10:12:40 +00:00
Ed Maste a5f384487a Remove expectedFailureFreeBSD from now-passing test
ExprCommandCallUserDefinedFunction::test_with_dwarf

llvm.org/pr20274

llvm-svn: 247596
2015-09-14 18:50:23 +00:00
Zachary Turner 2878bf44b1 [Windows] XFAIL tests that depend on expression name lookup.
Name lookup doesn't work properly with Windows targets.  This is
most likely due to issues with name mangling, although there is at
least one set of debug info related issues as well, since some of
the name lookup requests appear to be failing on types rather than
symbols.

Specifically, this patch XFAILS the following set of tests:

TestChar1632T.py
TestRdar12991846.py
TestConstVariables.py
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestCallUserDefinedFunction.py
TestCModules.py
TestCPPThis.py
TestExprs2.py
TestOverloadedFunctions.py
TestRvalueReferences.py

And fixing the underlying issue is tracked in http://llvm.org/pr24489

llvm-svn: 245338
2015-08-18 20:01:28 +00:00
Ewan Crawford 90ff791141 Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. 
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.

In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. 
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. 

The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.

Reviewers: jingham, spyffe

Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427

Differential Revision: http://reviews.llvm.org/D9404

llvm-svn: 242137
2015-07-14 10:56:58 +00:00