clayborg added a comment.

In https://reviews.llvm.org/D32167#1019467, @labath wrote:

> So, I tried this out on my machine, and got just one failure:
>
>   ======================================================================
>   FAIL: test_with_run_command_dwarf_type_units 
> (TestInlinedBreakpoints.InlinedBreakpointsTestCase)
>      Test 'b basic_types.cpp:176' does break (where int.cpp includes 
> basic_type.cpp).
>   ----------------------------------------------------------------------
>   Traceback (most recent call last):
>     File 
> "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 1827, in dwarf_type_units_test_method
>       return attrvalue(self)
>     File 
> "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/TestInlinedBreakpoints.py",
>  line 24, in test_with_run_command
>       self.inlined_breakpoints()
>     File 
> "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/TestInlinedBreakpoints.py",
>  line 46, in inlined_breakpoints
>       self, "basic_type.cpp", self.line, num_expected_locations=0)
>     File 
> "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lldbutil.py",
>  line 376, in run_break_set_by_file_and_line
>       num_locations=num_expected_locations)
>     File 
> "/usr/local/google/home/labath/ll/lldb/packages/Python/lldbsuite/test/lldbutil.py",
>  line 572, in check_breakpoint_result
>       out_num_locations))
>   AssertionError: False is not True : Expecting 0 locations, got 1.
>


I saw this too. When I ran _any_ of the variants manually, they all failed to 
set any breakpoints. Not sure this test is testing what it claims to be testing.

> However, I am not so sure about the proliferation of debug info variants that 
> we seem to be having. Right now we have two outstanding patches wanting to 
> add a debug variant, which would bring the total amount of variants per test 
> to 6. I'm not sure this is a tractable way forward.
>  IIUC, clang only puts "non-trivial" types in type units. I'm not sure how 
> many of our tests even define classes/structs (i.e., for how many tests this 
> debug info variant would actually be testing something new).

We could check after the build if the binary for the test even has a 
.debug_types sections and if not abort? That was we don't have to mark up the 
test in any way (like "this tests has structures or enums"), but we could 
ensure we test with .debug_types when needed.


https://reviews.llvm.org/D32167



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to