Re: [lldb-dev] test results look typical?

2015-08-25 Thread Todd Fiala via lldb-dev
On Tue, Aug 25, 2015 at 5:40 AM, Tamas Berghammer tbergham...@google.com wrote: Going back to the original question I think you have more test failures then expected. As Chaoren mentioned all TestDataFormatterLibc* tests are failing because of a missing dependency, Thanks, Tamas. I'm going

Re: [lldb-dev] test results look typical?

2015-08-25 Thread Todd Fiala via lldb-dev
So specifying CC=/usr/bin/gcc CXX=/usr/bin/g++ cmake -GNinja ... did the trick for getting rid of the libc++ issues. I think I may try to see if we can get those tests to make a run-time check to see if the inferior is linked against libc++, and if not, to skip it. We can have lldb do it by

Re: [lldb-dev] test results look typical?

2015-08-25 Thread via lldb-dev
On Tue, Aug 25, 2015 at 04:39:14PM -0700, Todd Fiala wrote: I may dig into that if nobody beats me to it. I did the original multiprocessing work on dosep ~1.5 years ago and it may be doing something goofy. Cool! It would be awesome if you could have a look - I've been meaning to dig

Re: [lldb-dev] Test suite rebuilding test executables many times

2015-08-25 Thread Jim Ingham via lldb-dev
It is fairly common practice (at least it is for me) when figuring out why a test failed, or adding to a test case, or when looking for a good example file to poke at, etc, to go to some relevant test directory, do a make then poke around a bunch. I don't generally remember to clean when I'm

Re: [lldb-dev] test results look typical?

2015-08-25 Thread Chaoren Lin via lldb-dev
Sorry, kernel bug is probably the wrong word. It's a problem specific to WMware. On Tue, Aug 25, 2015 at 4:25 PM, Chaoren Lin chaor...@google.com wrote: Are you running VMware by any chance? TestStepOverWatchpoint fails on VMware because of a kernel bug. On Tue, Aug 25, 2015 at 4:17 PM, Todd

[lldb-dev] Test suite rebuilding test executables many times

2015-08-25 Thread Zachary Turner via lldb-dev
While looking into a Windows-specific issue involving TestTargetAPI.py, I noticed that we are building the exact same executable many times. Every single test has a line such as self.buildDwarf() or self.buildDsym(). Those functions will first run make clean and then run make, essentially