[lldb-dev] settings set target.source-map question

2018-03-13 Thread Greg Clayton via lldb-dev 
When using "settings set target.source-map", when we try to set breakpoints by 
file and line, we try to undo any source remapping we did so we can set the 
breakpoint correctly:

BreakpointSP Target::CreateBreakpoint(const FileSpecList *containingModules,
  const FileSpec , uint32_t line_no,
  lldb::addr_t offset,
  LazyBool check_inlines,
  LazyBool skip_prologue, bool internal,
  bool hardware,
  LazyBool move_to_nearest_code) {
  FileSpec remapped_file;
  ConstString remapped_path;
  if (GetSourcePathMap().ReverseRemapPath(ConstString(file.GetPath().c_str()),
  remapped_path))
remapped_file.SetFile(remapped_path.AsCString(), true);
  else
remapped_file = file;


Note that the "remapped_file.SetFile(remapped_path.AsCString(), true);" is 
saying to resolve the path. I don't believe we want this path to resolve itself 
right?

I am currently running issues when using this with:

(lldb) settings set target.source-map ./ /Users/me/source

The debug info has all of the compilation directories set to "." and the 
resolving the path will cause the current working directory to be used when 
resolving the path and then we can't set breakpoints because the resolved path 
doesn't match. Any objections if I change the second argument to false so it 
doesn't resolve? I can't imagine we would want this reverse mapping to resolve??


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

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Vedant Kumar via lldb-dev 
As a first step, I think there's consensus on increasing the test timeout to 
~3x the length of the slowest test we know of. That test appears to be 
TestDataFormatterObjC, which takes 388 seconds on Davide's machine. So I 
propose 20 minutes as the timeout value.

Separately, regarding x-failed pexpect()-backed tests, I propose deleting them 
if they've been x-failed for over a year. That seems like a long enough time to 
wait for someone to step up and fix them given that they're a real 
testing/maintenance burden. For any group of to-be-deleted tests, like the 22 
lldb-mi tests x-failed in all configurations, I'd file a PR about potentially 
bringing the tests back. Thoughts?

thanks,
vedant

> On Mar 13, 2018, at 11:52 AM, Davide Italiano  wrote:
> 
> On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham  wrote:
>> It sounds like we timing out based on the whole test class, not the 
>> individual tests?  If you're worried about test failures not hanging up the 
>> test suite the you really want to do the latter.
>> 
>> These are all tests that contain 5 or more independent tests.  That's 
>> probably why they are taking so long to run.
>> 
>> I don't object to having fairly long backstop timeouts, though I agree with 
>> Pavel that we should choose something reasonable based on the slowest 
>> running tests just so some single error doesn't cause test runs to just 
>> never complete, making analysis harder.
>> 
> 
> Vedant (cc:ed) is going to take a look at this as he's babysitting the
> bots for the week. I'll defer the call to him.

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

Re: [lldb-dev] tests xfailed globally with radar references

2018-03-13 Thread Vedant Kumar via lldb-dev 
I took a first cut at this in r327463.

vedant

> On Mar 13, 2018, at 2:39 PM, Vedant Kumar  wrote:
> 
> Hi Ted,
> 
> Thanks for bringing this up. I'll volunteer to take a look at these tests and 
> file PRs where appropriate. I should get to this within a day or two.
> 
> vedant
> 
>> On Mar 13, 2018, at 10:31 AM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I was investigating TestWatchedVarHitWhenInScope.py, which tests that a
>> watchpoint is hit in scope and not hit when out of scope. It's xfailed due
>> to a radar:
>>   @unittest2.expectedFailure("rdar://problem/18685649")
>> 
>> This is an actual bug - watchpoints are hit when the address is modified but
>> the variable is out of scope. Which can happen a lot if the variable being
>> watched is a local on the stack. I manually ran the testcase on Linux, and
>> it failed when it hit the watchpoint out of scope:
>> Process 18652 stopped
>> * thread #1, name = 'a.out', stop reason = watchpoint 1
>>   frame #0: 0x7722d0d2 libc.so.6`__run_exit_handlers(status=0,
>> listp=0x775b36c8, run_list_atexit=true) at exit.c:35
>> 
>> A google search found this message, posted by Ed Maste to llvm-dev:
>> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116471.html .
>> 
>> I echo Ed's request - could someone at Apple look at these radars, and open
>> llvm bugs for the ones that aren't Darwin-only?
>> 
>> 
>> Ed's message:
>> 
>> I was recently looking at an unexpected pass test result on FreeBSD[1]
>> which is decorated with expectedFailureAll referencing
>> rdar://problem/24599697. I'm looking for more details on this specific
>> radar bug report in order to determine if the test is not exercising
>> the original bug on FreeBSD, or if it's really an Apple-only issue.
>> 
>> As it's rather unfortunate to have a bug report reference for which no
>> further public details are available I looked at other radar
>> references in the test suite, and found 118 of them. Many of these are
>> in comments, in macosx-specific cases (e.g.
>> @expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28805064")),
>> or in tests decorated with skipUnlessDarwin, and I've ignored those.
>> 
>> There are 10 tests with expected failure decorators, and one skipped,
>> that apply beyond macosx and reference a radar (and do not
>> additionally reference an LLVM PR). Can someone at Apple check these
>> radar references and submit LLVM PRs, reference existing PRs, add a
>> reasonable description in the test source, etc. as appropriate?
>> 
>> functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScop
>> e.py
>> unittest2.expectedFailure("rdar://problem/18685649")
>> 
>> functionalities/asan/TestReportData.py
>> @expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")
>> 
>> api/multiple-debuggers/TestMultipleDebuggers.py
>> @expectedFailureAll(bugnumber="rdar://30564102")
>> 
>> lang/objc/bitfield_ivars/TestBitfieldIvars.py
>> decorators.expectedFailureAll(bugnumber="rdar://problem/17990991")])
>> 
>> lang/c/shared_lib/TestSharedLib.py
>> @unittest2.expectedFailure("rdar://problem/10704639")
>> 
>> lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
>> @unittest2.expectedFailure("rdar://problem/10381325")
>> 
>> lang/cpp/stl/TestSTL.py
>> @expectedFailureAll(bugnumber="rdar://problem/10400981")
>> 
>> lang/cpp/dynamic-value/TestCppValueCast.py
>> @unittest2.expectedFailure("rdar://problem/10808472 SBValue::Cast test
>> case is failing (virtual inheritance)")
>> 
>> lang/cpp/printf/TestPrintf.py
>> decorators.expectedFailureAll(bugnumber="rdar://problem/24599697")])
>> 
>> lang/cpp/function-template-parameter-pack/TestFunctionTemplateParameterPack.
>> py
>> decorators.expectedFailureAll(bugnumber="rdar://problem/32096064")])
>> 
>> lang/cpp/unique-types/TestUniqueTypes.py
>> self.skipTest("rdar://problem/9173060 lldb hangs while running
>> unique-types for clang version < 3")
>> 
>> [1]
>> http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20170807/036634.htm
>> l
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>> 
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

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

[lldb-dev] [Bug 36715] New: Expression evaluation of printf is incorrect (TestPrintf.py)

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36715

Bug ID: 36715
   Summary: Expression evaluation of printf is incorrect
(TestPrintf.py)
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org

The expr evaluator claims printf("Hello\n") returns 0, but it should return 6.
This was tracked as rdar://24599697 and mistakenly closed, it seems.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36714] New: No support for SBValue::Cast() for C++ types with virtual inheritance

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36714

Bug ID: 36714
   Summary: No support for SBValue::Cast() for C++ types with
virtual inheritance
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org

The test_value_cast_with_virtual_inheritance will be skipped until we decide to
support this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36713] New: TestSTL.py fails because "expr associative_array.size()" fails

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36713

Bug ID: 36713
   Summary: TestSTL.py fails because "expr
associative_array.size()" fails
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org

FAIL: test_gmodules (TestSTL.STLTestCase)
   Test some expressions involving STL data types.
--
Traceback (most recent call last):
  File
"/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1799, in gmodules_test_method
return attrvalue(self)
  File
"/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/stl/TestSTL.py",
line 65, in test
substrs=[' = 3'])
  File
"/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2227, in expect
inHistory=inHistory)
  File
"/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2120, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'expr associative_array.size()'
returns successfully
Config=x86_64-/Users/vsk/src/builds/llvm.org-lldbsan-RA/bin/clang-7.0
--
Ran 6 tests in 10.711s

RESULT: FAILED (3 passes, 3 failures, 0 errors, 0 skipped, 0 expected failures,
0 unexpected successes)

[TestSTL.py FAILED]
Command invoked: /usr/bin/python
/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /Users/vsk/src/builds/llvm.org-lldbsan-RA/bin/lldb -s
/Users/vsk/src/builds/llvm.org-lldbsan-RA/lldb-test-traces --build-dir
/Users/vsk/src/builds/llvm.org-lldbsan-RA/lldb-test-build.noindex -S nm -u
CXXFLAGS -u CFLAGS -C /Users/vsk/src/builds/llvm.org-lldbsan-RA/./bin/clang
--server
/Volumes/Xcode9E129_m17E168_i15E197_t15L194_w15T195_b15P3158_XcodeInternals_32bitSupport_FastSim_Boost_ASan_29GB/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/debugserver
--out-of-tree-debugserver -p TestSTL --results-port 59269 -S nm --inferior -p
TestSTL.py
/Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/stl
--event-add-entries worker_index=0:int
  1 out of 617 test suites processed - TestSTL.py
=
Issue Details
=
FAIL: test_dsym (lang/cpp/stl/TestSTL.py)
FAIL: test_dwarf (lang/cpp/stl/TestSTL.py)
FAIL: test_gmodules (lang/cpp/stl/TestSTL.py)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36712] New: frame var can't access types defined in another shared object from the one holding the current frame

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36712

Bug ID: 36712
   Summary: frame var can't access types defined in another shared
object from the one holding the current frame
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org

We don't support "frame var" on a variable which has a type defined in another
module:

* thread #1: tid = 0x1f07, 0x00010edd two-libs`main + 45 at main.c:10,
stop reason = breakpoint 1.1
frame #0: 0x00010edd two-libs`main + 45 at main.c:10
   7  struct foo *my_foo_ptr;
   8  my_foo_ptr = GetMeAFoo();
   9  
-> 10 printf ("My sub foo has: %d.\n", GetMeASubFoo(my_foo_ptr)->sub_1);
   11   
   12 return 0;
   13   }
(lldb) frame var *my_foo_ptr
error: dereference failed: (foo *) my_foo_ptr
(lldb) expr (*my_foo_ptr)
(foo) $0 = {}
(lldb) image lookup -t foo
1 match found in libfoo.dylib:
id = {0x1012e}, name = "foo", byte-size = 24, decl = foo.c:4, clang_type =
"struct foo {
sub_foo sub_element;
int other_element;
}"

Note we know the type, but it is in the module libfoo.dylib.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36711] TestMultipleSimultaneousDebuggers fails non-deterministically

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36711

Vedant Kumar  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Vedant Kumar  ---


*** This bug has been marked as a duplicate of bug 20282 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] tests xfailed globally with radar references

2018-03-13 Thread Vedant Kumar via lldb-dev 
Hi Ted,

Thanks for bringing this up. I'll volunteer to take a look at these tests and 
file PRs where appropriate. I should get to this within a day or two.

vedant
 
> On Mar 13, 2018, at 10:31 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I was investigating TestWatchedVarHitWhenInScope.py, which tests that a
> watchpoint is hit in scope and not hit when out of scope. It's xfailed due
> to a radar:
>@unittest2.expectedFailure("rdar://problem/18685649")
> 
> This is an actual bug - watchpoints are hit when the address is modified but
> the variable is out of scope. Which can happen a lot if the variable being
> watched is a local on the stack. I manually ran the testcase on Linux, and
> it failed when it hit the watchpoint out of scope:
> Process 18652 stopped
> * thread #1, name = 'a.out', stop reason = watchpoint 1
>frame #0: 0x7722d0d2 libc.so.6`__run_exit_handlers(status=0,
> listp=0x775b36c8, run_list_atexit=true) at exit.c:35
> 
> A google search found this message, posted by Ed Maste to llvm-dev:
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116471.html .
> 
> I echo Ed's request - could someone at Apple look at these radars, and open
> llvm bugs for the ones that aren't Darwin-only?
> 
> 
> Ed's message:
> 
> I was recently looking at an unexpected pass test result on FreeBSD[1]
> which is decorated with expectedFailureAll referencing
> rdar://problem/24599697. I'm looking for more details on this specific
> radar bug report in order to determine if the test is not exercising
> the original bug on FreeBSD, or if it's really an Apple-only issue.
> 
> As it's rather unfortunate to have a bug report reference for which no
> further public details are available I looked at other radar
> references in the test suite, and found 118 of them. Many of these are
> in comments, in macosx-specific cases (e.g.
> @expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28805064")),
> or in tests decorated with skipUnlessDarwin, and I've ignored those.
> 
> There are 10 tests with expected failure decorators, and one skipped,
> that apply beyond macosx and reference a radar (and do not
> additionally reference an LLVM PR). Can someone at Apple check these
> radar references and submit LLVM PRs, reference existing PRs, add a
> reasonable description in the test source, etc. as appropriate?
> 
> functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScop
> e.py
> unittest2.expectedFailure("rdar://problem/18685649")
> 
> functionalities/asan/TestReportData.py
> @expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")
> 
> api/multiple-debuggers/TestMultipleDebuggers.py
> @expectedFailureAll(bugnumber="rdar://30564102")
> 
> lang/objc/bitfield_ivars/TestBitfieldIvars.py
> decorators.expectedFailureAll(bugnumber="rdar://problem/17990991")])
> 
> lang/c/shared_lib/TestSharedLib.py
> @unittest2.expectedFailure("rdar://problem/10704639")
> 
> lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
> @unittest2.expectedFailure("rdar://problem/10381325")
> 
> lang/cpp/stl/TestSTL.py
> @expectedFailureAll(bugnumber="rdar://problem/10400981")
> 
> lang/cpp/dynamic-value/TestCppValueCast.py
> @unittest2.expectedFailure("rdar://problem/10808472 SBValue::Cast test
> case is failing (virtual inheritance)")
> 
> lang/cpp/printf/TestPrintf.py
> decorators.expectedFailureAll(bugnumber="rdar://problem/24599697")])
> 
> lang/cpp/function-template-parameter-pack/TestFunctionTemplateParameterPack.
> py
> decorators.expectedFailureAll(bugnumber="rdar://problem/32096064")])
> 
> lang/cpp/unique-types/TestUniqueTypes.py
> self.skipTest("rdar://problem/9173060 lldb hangs while running
> unique-types for clang version < 3")
> 
> [1]
> http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20170807/036634.htm
> l
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Davide Italiano via lldb-dev 
On Tue, Mar 13, 2018 at 11:26 AM, Jim Ingham  wrote:
> It sounds like we timing out based on the whole test class, not the 
> individual tests?  If you're worried about test failures not hanging up the 
> test suite the you really want to do the latter.
>
> These are all tests that contain 5 or more independent tests.  That's 
> probably why they are taking so long to run.
>
> I don't object to having fairly long backstop timeouts, though I agree with 
> Pavel that we should choose something reasonable based on the slowest running 
> tests just so some single error doesn't cause test runs to just never 
> complete, making analysis harder.
>

Vedant (cc:ed) is going to take a look at this as he's babysitting the
bots for the week. I'll defer the call to him.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Jim Ingham via lldb-dev 
It sounds like we timing out based on the whole test class, not the individual 
tests?  If you're worried about test failures not hanging up the test suite the 
you really want to do the latter.

These are all tests that contain 5 or more independent tests.  That's probably 
why they are taking so long to run.  

I don't object to having fairly long backstop timeouts, though I agree with 
Pavel that we should choose something reasonable based on the slowest running 
tests just so some single error doesn't cause test runs to just never complete, 
making analysis harder.

Jim

> On Mar 13, 2018, at 10:43 AM, Davide Italiano  wrote:
> 
> Few examples:
> 
> 360 out of 617 test suites processed - TestObjCMethods.py
> XX
> TestObjCMethods.py: 363.726592
> 381 out of 617 test suites processed - TestHiddenIvars.py
>XX
>  TestHiddenIvars.py: 363.887766
> 387 out of 617 test suites processed - TestObjCNewSyntax.py
>   XX
> TestObjCNewSyntax.py: 363.842807
> 600 out of 617 test suites processed - TestDataFormatterObjC.py
> XX
> TestDataFormatterObjC.py: 388.414883
> 617 out of 617 test suites processed - TestLoadUnload.py
>  XX
> TestLoadUnload.py: 363.372328
> 
> On Tue, Mar 13, 2018 at 9:49 AM, Davide Italiano  
> wrote:
>> I'll re-run the test and send you a list.
>> 
>> Thank you!
>> 
>> --
>> Davide
>> 
>> On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath  wrote:
>>> Aha, in that case, it definitely sounds like increasing the timeout is in
>>> order. I would still go for something less than 30 minutes, but I don't care
>>> about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if
>>> tests taking long to time out start bugging me.
>>> 
>>> BTW, do you know which test is that? Is it one of the tests I have listed in
>>> one of the previous emails?
>>> 
>>> On Tue, 13 Mar 2018 at 14:52, Davide Italiano  wrote:
 
 On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath  wrote:
> I think we should get some data before pulling numbers out of our
> sleeves.
> If we can get some numbers on the slowest machine that we have around,
> then
> we should be able to specify the timeout as some multiple of the slowest
> test. For example, for me the slowest test takes around 110 seconds. The
> timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long
> does
> the slowest test take for you? If we set the timeout as 3x or 4x that
> number, we should create a sufficiently large buffer and still avoid
> half-hour waits.
> 
 
 The longest test takes over 300 seconds. This is a late 2013 Mac Pro,
 so, definitely not the newest machine out there (but also something
 fairly high spec).
 For the archives, my conf is something like; cmake -GNinja ../llvm &&
 ninja check-lldb
 
 Thanks!
 
 --
 Davide

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

[lldb-dev] tests xfailed globally with radar references

2018-03-13 Thread Ted Woodward via lldb-dev 
I was investigating TestWatchedVarHitWhenInScope.py, which tests that a
watchpoint is hit in scope and not hit when out of scope. It's xfailed due
to a radar:
@unittest2.expectedFailure("rdar://problem/18685649")

This is an actual bug - watchpoints are hit when the address is modified but
the variable is out of scope. Which can happen a lot if the variable being
watched is a local on the stack. I manually ran the testcase on Linux, and
it failed when it hit the watchpoint out of scope:
Process 18652 stopped
* thread #1, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x7722d0d2 libc.so.6`__run_exit_handlers(status=0,
listp=0x775b36c8, run_list_atexit=true) at exit.c:35

A google search found this message, posted by Ed Maste to llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116471.html .

I echo Ed's request - could someone at Apple look at these radars, and open
llvm bugs for the ones that aren't Darwin-only?


Ed's message:

I was recently looking at an unexpected pass test result on FreeBSD[1]
which is decorated with expectedFailureAll referencing
rdar://problem/24599697. I'm looking for more details on this specific
radar bug report in order to determine if the test is not exercising
the original bug on FreeBSD, or if it's really an Apple-only issue.

As it's rather unfortunate to have a bug report reference for which no
further public details are available I looked at other radar
references in the test suite, and found 118 of them. Many of these are
in comments, in macosx-specific cases (e.g.
@expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28805064")),
or in tests decorated with skipUnlessDarwin, and I've ignored those.

There are 10 tests with expected failure decorators, and one skipped,
that apply beyond macosx and reference a radar (and do not
additionally reference an LLVM PR). Can someone at Apple check these
radar references and submit LLVM PRs, reference existing PRs, add a
reasonable description in the test source, etc. as appropriate?

functionalities/watchpoint/variable_out_of_scope/TestWatchedVarHitWhenInScop
e.py
unittest2.expectedFailure("rdar://problem/18685649")

functionalities/asan/TestReportData.py
@expectedFailureAll(archs=['i386'], bugnumber="rdar://28658860")

api/multiple-debuggers/TestMultipleDebuggers.py
@expectedFailureAll(bugnumber="rdar://30564102")

lang/objc/bitfield_ivars/TestBitfieldIvars.py
decorators.expectedFailureAll(bugnumber="rdar://problem/17990991")])

lang/c/shared_lib/TestSharedLib.py
@unittest2.expectedFailure("rdar://problem/10704639")

lang/c/shared_lib_stripped_symbols/TestSharedLibStrippedSymbols.py
@unittest2.expectedFailure("rdar://problem/10381325")

lang/cpp/stl/TestSTL.py
@expectedFailureAll(bugnumber="rdar://problem/10400981")

lang/cpp/dynamic-value/TestCppValueCast.py
@unittest2.expectedFailure("rdar://problem/10808472 SBValue::Cast test
case is failing (virtual inheritance)")

lang/cpp/printf/TestPrintf.py
decorators.expectedFailureAll(bugnumber="rdar://problem/24599697")])

lang/cpp/function-template-parameter-pack/TestFunctionTemplateParameterPack.
py
decorators.expectedFailureAll(bugnumber="rdar://problem/32096064")])

lang/cpp/unique-types/TestUniqueTypes.py
self.skipTest("rdar://problem/9173060 lldb hangs while running
unique-types for clang version < 3")

[1]
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20170807/036634.htm
l

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project


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

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Davide Italiano via lldb-dev 
I'll re-run the test and send you a list.

Thank you!

--
Davide

On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath  wrote:
> Aha, in that case, it definitely sounds like increasing the timeout is in
> order. I would still go for something less than 30 minutes, but I don't care
> about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if
> tests taking long to time out start bugging me.
>
> BTW, do you know which test is that? Is it one of the tests I have listed in
> one of the previous emails?
>
> On Tue, 13 Mar 2018 at 14:52, Davide Italiano  wrote:
>>
>> On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath  wrote:
>> > I think we should get some data before pulling numbers out of our
>> > sleeves.
>> > If we can get some numbers on the slowest machine that we have around,
>> > then
>> > we should be able to specify the timeout as some multiple of the slowest
>> > test. For example, for me the slowest test takes around 110 seconds. The
>> > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long
>> > does
>> > the slowest test take for you? If we set the timeout as 3x or 4x that
>> > number, we should create a sufficiently large buffer and still avoid
>> > half-hour waits.
>> >
>>
>> The longest test takes over 300 seconds. This is a late 2013 Mac Pro,
>> so, definitely not the newest machine out there (but also something
>> fairly high spec).
>> For the archives, my conf is something like; cmake -GNinja ../llvm &&
>> ninja check-lldb
>>
>> Thanks!
>>
>> --
>> Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Pavel Labath via lldb-dev 
Aha, in that case, it definitely sounds like increasing the timeout is in
order. I would still go for something less than 30 minutes, but I don't
care about that much. I may just export LLDB_TEST_TIMEOUT locally to lower
it if tests taking long to time out start bugging me.

BTW, do you know which test is that? Is it one of the tests I have listed
in one of the previous emails?

On Tue, 13 Mar 2018 at 14:52, Davide Italiano  wrote:

> On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath  wrote:
> > I think we should get some data before pulling numbers out of our
> sleeves.
> > If we can get some numbers on the slowest machine that we have around,
> then
> > we should be able to specify the timeout as some multiple of the slowest
> > test. For example, for me the slowest test takes around 110 seconds. The
> > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long
> does
> > the slowest test take for you? If we set the timeout as 3x or 4x that
> > number, we should create a sufficiently large buffer and still avoid
> > half-hour waits.
> >
>
> The longest test takes over 300 seconds. This is a late 2013 Mac Pro,
> so, definitely not the newest machine out there (but also something
> fairly high spec).
> For the archives, my conf is something like; cmake -GNinja ../llvm &&
> ninja check-lldb
>
> Thanks!
>
> --
> Davide
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

2018-03-13 Thread Greg Clayton via lldb-dev 
Good catch Pavel, I missed that part where it calls Index manually even if we 
have accelerator tables where we don't need to manually index. 

We should modify SymbolFileDWARF::Index() that currently looks like:


void SymbolFileDWARF::Index() {
  if (m_indexed)
return;
...
}


To look like:


bool SymbolFileDWARF::HasFullIndex() const {
  return m_using_apple_tables;
}

void SymbolFileDWARF::Index() {
  if (m_indexed || HasFullIndex())
return;
...
}


SymbolFileDWARF::HasFullIndex() is a new function we need to add. Then as we 
update LLDB to handle new accelerator tables, like the new DWARF 5 tables Pavel 
is working on getting checked into LLVM and LLDB, we can update 
SymbolFileDWARF::HasFullIndex() as needed. This should return the high 
performance on systems with full accelerator tables. Let us know if this works.


Greg Clayton


> On Mar 13, 2018, at 2:56 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> I would start by looking at https://reviews.llvm.org/D32598 
> , which adds a bunch of work we do up-front. 
> I remember looking at this a while back and not being sure whether all of 
> that work is relevant for osx, actually. (I'm specifically thinking of the 
> SymbolFileDWARF::Index call, which is done unconditionally, but I think that 
> index is unused if we have accelerator tables).
> 
> On Mon, 12 Mar 2018 at 21:59, Adrian Prantl via lldb-dev 
> > wrote:
> If this is a Mac I would recommend to build both lldbs in RelWithDebInfo mode 
> and then run them through Instruments and compare the traces. I'd be very 
> interested in learning what the cause for the slowdown is.
> 
> -- adrian
> 
> > On Mar 12, 2018, at 2:57 PM, Timothee Cour  > > wrote:
> >
> > after further inspection it turns out it's a performance regression
> > between llvm 5 and llvm 6:
> >
> > $homebrew_D/Cellar/llvm/5.0.1/lldb -s test_lldb.txt -- prog
> > 8 seconds
> > $homebrew_D/Cellar/llvm/6.0.0/bin/lldb -s test_lldb.txt -- prog
> > 40 seconds
> >
> > cat test_lldb.txt:
> > ```
> > b FOO
> > r
> > bt
> > q
> > ```
> >
> > prog is some binary I'm debugging. It's unfortunately hard to reduce.
> > What are good ways to investigate this?
> >
> >
> >
> > On Mon, Mar 12, 2018 at 1:42 PM, Adrian Prantl  > > wrote:
> >> Have you tried diff'ing your cmake invocation against the on used by 
> >> homebrew?
> >>
> >> -- adrian
> >>
> >>> On Mar 9, 2018, at 12:59 AM, Timothee Cour via lldb-dev 
> >>> > wrote:
> >>>
> >>> while testing out https://github.com/llvm-mirror/lldb/pull/3 
> >>>  I noticed
> >>> that when I compiled lldb from source (even un-modified from git HEAD)
> >>> it was 5X slower than homebrew lldb or default lldb:
> >>>
> >>> I'm compiling lldb as follows:
> >>> ```
> >>> git clone https://github.com/llvm-mirror/llvm.git 
> >>> 
> >>> cd llvm/tools
> >>> git clone https://github.com/llvm-mirror/lldb 
> >>> 
> >>> ## also, patch in https://github.com/llvm-mirror/lldb/pull/3 
> >>> 
> >>> git clone https://github.com/llvm-mirror/clang 
> >>> 
> >>> cd ..
> >>> mkdir build
> >>> cd build
> >>> ccmake .. -G Ninja
> >>> # here I set: CMAKE_BUILD_TYPE  Release
> >>> ninja all
> >>> ```
> >>>
> >>> I also tried setting `LLVM_ENABLE_ASSERTIONS OFF` but no difference
> >>>
> >>>
> >>> commands.txt
> >>> ```
> >>> b FOO
> >>> r
> >>> bt
> >>> q
> >>> ```
> >>>
> >>> ./test is some program i have.
> >>>
> >>> ```
> >>> time lldb -s commands.txt -- ./test
> >>> 8 seconds
> >>> time ./build/bin/lldb -s commands.txt -- ./test
> >>> 40 seconds
> >>> ```
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org 
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> >>> 
> >>
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Davide Italiano via lldb-dev 
On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath  wrote:
> I think we should get some data before pulling numbers out of our sleeves.
> If we can get some numbers on the slowest machine that we have around, then
> we should be able to specify the timeout as some multiple of the slowest
> test. For example, for me the slowest test takes around 110 seconds. The
> timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long does
> the slowest test take for you? If we set the timeout as 3x or 4x that
> number, we should create a sufficiently large buffer and still avoid
> half-hour waits.
>

The longest test takes over 300 seconds. This is a late 2013 Mac Pro,
so, definitely not the newest machine out there (but also something
fairly high spec).
For the archives, my conf is something like; cmake -GNinja ../llvm &&
ninja check-lldb

Thanks!

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] increase timeout for tests?

2018-03-13 Thread Pavel Labath via lldb-dev 
I think we should get some data before pulling numbers out of our sleeves.
If we can get some numbers on the slowest machine that we have around, then
we should be able to specify the timeout as some multiple of the slowest
test. For example, for me the slowest test takes around 110 seconds. The
timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long does
the slowest test take for you? If we set the timeout as 3x or 4x that
number, we should create a sufficiently large buffer and still avoid
half-hour waits.

On Tue, 13 Mar 2018 at 02:54, Davide Italiano  wrote:

> On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham  wrote:
> > The problem with having no timeouts is that you have to then be fairly
> careful how you write tests.  You can't do:
> >
> > while (1) {
> >print("Set a breakpoint here and hit it a few times then stop the
> test");
> > }
> >
> > because if the breakpoint setting fails the test can run forever.  And
> we wait forever to launch or attach to a process internally in lldb, so if
> you mess up attaching or launching in some situation, that again makes the
> test run forever.  The timeouts are a backstop so you will get useful
> results from the testsuite in the case of this sort of error.
> >
>
> I see this. So, maybe we should set this to a ridiculously large value
> (e.g. 30/60 minutes)? FWIW, I have at home that's slow enough that the
> testsuite times out more often, and that's not great (the funny part
> is that there's nothing inherently wrong with the tests :) Would you
> be fine with such a middle ground, Jim?
>
> Thanks,
>
> --
> Davide
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb compiled from source 5X slower than homebrew or default lldb

2018-03-13 Thread Pavel Labath via lldb-dev 
I would start by looking at https://reviews.llvm.org/D32598, which adds a
bunch of work we do up-front. I remember looking at this a while back and
not being sure whether all of that work is relevant for osx, actually. (I'm
specifically thinking of the SymbolFileDWARF::Index call, which is done
unconditionally, but I think that index is unused if we have accelerator
tables).

On Mon, 12 Mar 2018 at 21:59, Adrian Prantl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> If this is a Mac I would recommend to build both lldbs in RelWithDebInfo
> mode and then run them through Instruments and compare the traces. I'd be
> very interested in learning what the cause for the slowdown is.
>
> -- adrian
>
> > On Mar 12, 2018, at 2:57 PM, Timothee Cour 
> wrote:
> >
> > after further inspection it turns out it's a performance regression
> > between llvm 5 and llvm 6:
> >
> > $homebrew_D/Cellar/llvm/5.0.1/lldb -s test_lldb.txt -- prog
> > 8 seconds
> > $homebrew_D/Cellar/llvm/6.0.0/bin/lldb -s test_lldb.txt -- prog
> > 40 seconds
> >
> > cat test_lldb.txt:
> > ```
> > b FOO
> > r
> > bt
> > q
> > ```
> >
> > prog is some binary I'm debugging. It's unfortunately hard to reduce.
> > What are good ways to investigate this?
> >
> >
> >
> > On Mon, Mar 12, 2018 at 1:42 PM, Adrian Prantl 
> wrote:
> >> Have you tried diff'ing your cmake invocation against the on used by
> homebrew?
> >>
> >> -- adrian
> >>
> >>> On Mar 9, 2018, at 12:59 AM, Timothee Cour via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>>
> >>> while testing out https://github.com/llvm-mirror/lldb/pull/3 I noticed
> >>> that when I compiled lldb from source (even un-modified from git HEAD)
> >>> it was 5X slower than homebrew lldb or default lldb:
> >>>
> >>> I'm compiling lldb as follows:
> >>> ```
> >>> git clone https://github.com/llvm-mirror/llvm.git
> >>> cd llvm/tools
> >>> git clone https://github.com/llvm-mirror/lldb
> >>> ## also, patch in https://github.com/llvm-mirror/lldb/pull/3
> >>> git clone https://github.com/llvm-mirror/clang
> >>> cd ..
> >>> mkdir build
> >>> cd build
> >>> ccmake .. -G Ninja
> >>> # here I set: CMAKE_BUILD_TYPE  Release
> >>> ninja all
> >>> ```
> >>>
> >>> I also tried setting `LLVM_ENABLE_ASSERTIONS OFF` but no difference
> >>>
> >>>
> >>> commands.txt
> >>> ```
> >>> b FOO
> >>> r
> >>> bt
> >>> q
> >>> ```
> >>>
> >>> ./test is some program i have.
> >>>
> >>> ```
> >>> time lldb -s commands.txt -- ./test
> >>> 8 seconds
> >>> time ./build/bin/lldb -s commands.txt -- ./test
> >>> 40 seconds
> >>> ```
> >>> ___
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 36694] LLDB compile error on s390x

2018-03-13 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=36694

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
(Hopefully) fixed by r327379. Note, I have no way of verifying this builds, so
if things are still broken after this, please come with a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev