The first and second issues (cleaning once at startup, switching between
dsym and dwarf tests) can probably both be solved at the same time by
having the test runner sort the runs and do all dsym tests first, and then
all dwarf tests, and having TestBase do make clean once before each of
those step
On Tue, Aug 25, 2015 at 4:41 PM, Todd Fiala wrote:
> Hi Chaoren,
>
> Right you are, I am using a VMWare VM. Usually when I have issues with
> VMs, it is because I'm not using VMWare, so this is a change!
>
>
And I am happy to report I get *no* errors when building with clang-3.6 +
ld.gold + Debu
On Tue, Aug 25, 2015 at 4:43 PM, Zachary Turner wrote:
>
>
> On Tue, Aug 25, 2015 at 4:39 PM Todd Fiala wrote:
>
>>
>> Great, thanks Dawn!
>>
>> I'd like to get all the counts into dosep.py at least as an option, but
>> having something to cross check it with is good (and getting a quick answer
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
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
fur
Another possibility is changing the arguments to buildDwarf and buildDsym.
Currently they take a clean argument with a default value of True. Does
this really need to be True? If this were False by default it could
drastically speed up the test suite. And I can't think of a reason why
make clean
On Tue, Aug 25, 2015 at 4:39 PM Todd Fiala wrote:
>
> Great, thanks Dawn!
>
> I'd like to get all the counts into dosep.py at least as an option, but
> having something to cross check it with is good (and getting a quick answer
> is nice as well, thanks.)
>
Personally I'd love to see LESS option
Hi Chaoren,
Right you are, I am using a VMWare VM. Usually when I have issues with
VMs, it is because I'm not using VMWare, so this is a change!
Do you have a reference to a VMWare bug on this? That would be great to
follow up with them on.
In the absence of that, I wonder if we can detect tha
On Tue, Aug 25, 2015 at 4:22 PM, wrote:
> On Tue, Aug 25, 2015 at 04:41:34PM +, Zachary Turner wrote:
> > It would be great (and not too difficult) to add skip counts to dosep. I
> > modified dotest so it formats the result summary in a nice single string
> > that you can regex match to get
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
rebuildi
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 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 Fiala 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 Fiala wrote:
> One more data point:
>
> Building/testing on Ubuntu 14.04.3 built with clang-3.6 and the ld.gold
> linker yielded the following test results,
On Tue, Aug 25, 2015 at 04:41:34PM +, Zachary Turner wrote:
> It would be great (and not too difficult) to add skip counts to dosep. I
> modified dotest so it formats the result summary in a nice single string
> that you can regex match to get counts. It's already matched in dosep, but
> we j
One more data point:
Building/testing on Ubuntu 14.04.3 built with clang-3.6 and the ld.gold
linker yielded the following test results, bringing me down to a single
failure (and was 1.6x faster than a Debug build with gcc-4.9 and ld.bfd, 12
GB RAM and 6 cores allocated):
Failing Tests (1)
FAIL: L
Thanks, we should probably do something like that after this release,
but for now I think it's best to revert to safety.
On Tue, Aug 25, 2015 at 2:44 PM, Dimitry Andric wrote:
> Hans,
>
> Note that the patches I posted solved the problems, at least for me. :)
>
> -Dimitry
>
>> On 25 Aug 2015, at
https://llvm.org/bugs/show_bug.cgi?id=24579
Bug ID: 24579
Summary: settings.target-env-vars doesn't work correctly on
Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status
Hans,
Note that the patches I posted solved the problems, at least for me. :)
-Dimitry
> On 25 Aug 2015, at 01:40, Hans Wennborg wrote:
>
> It seems this is a cmake vs autoconf thing. With cmake, it builds
> correctly, but with autoconf I get the same error as you.
>
> I probably shouldn't ha
On Tue, Aug 25, 2015 at 8:45 AM, Tamas Berghammer
wrote:
> Hi Todd,
>
> I am using a clang-3.5 build release LLDB to debug an other clang-3.5
> build debug LLDB on Linux x86_64 and it works pretty well for me (works
> better then using GDB). The most issue I am hitting is around expression
> eval
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 look
https://llvm.org/bugs/show_bug.cgi?id=24575
Bug ID: 24575
Summary: ERRORs running lldb tests on OSX via dotest.py after
TestDisassemble_VST1_64
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Okay.
So the culprit then is that I'm using:
cmake -GNinja ../llvm
with one extra flag for build type. And cmake is then just choosing
/usr/bin/cc.
We could improve this by having the compiler symbolic links fully resolved:
/usr/bin/cc -> /etc/alternatives/cc -> /usr/bin/gcc, which would have t
In theory the test should be skipped when you are using gcc (cc is an alias
for it) but we detect the type of the compiler based on the executable name
and in case of cc we don't recognize that it is a gcc, so we don't skip the
test.
On Tue, Aug 25, 2015 at 5:45 PM Chaoren Lin via lldb-dev <
lldb-
You're using CC="/usr/bin/cc". It needs to be clang for USE_LIBCPP to do
anything. :/
On Tue, Aug 25, 2015 at 9:20 AM, Todd Fiala wrote:
> Here are a couple of the failures that came up (the log output from the
> full dosep.py run).
>
> Let me know if that is not sufficient!
>
> On Tue, Aug 25,
It would be great (and not too difficult) to add skip counts to dosep. I
modified dotest so it formats the result summary in a nice single string
that you can regex match to get counts. It's already matched in dosep, but
we just aren't pulling out the skip counts. So it would be very easy to
add
Here are a couple of the failures that came up (the log output from the
full dosep.py run).
Let me know if that is not sufficient!
On Tue, Aug 25, 2015 at 9:14 AM, Pavel Labath wrote:
> There's no need to do anything fancy (yet :) ). For initial diagnosis
> the output of `./dotest.py $your_usua
There's no need to do anything fancy (yet :) ). For initial diagnosis
the output of `./dotest.py $your_usual_options -p SomeLibcxxTest.py
-t` should suffice.
pl
On 25 August 2015 at 16:45, Todd Fiala wrote:
> Thanks, Pavel! I'll dig that up and get back.
>
> On Tue, Aug 25, 2015 at 8:30 AM, Pav
Hi Todd,
I am using a clang-3.5 build release LLDB to debug an other clang-3.5 build
debug LLDB on Linux x86_64 and it works pretty well for me (works better
then using GDB). The most issue I am hitting is around expression
evaluation when I can't execute very small functions in std:: objects, but
Thanks, Pavel! I'll dig that up and get back.
On Tue, Aug 25, 2015 at 8:30 AM, Pavel Labath wrote:
> There is no separate option, it should just work. :)
>
> I'm betting you are still missing some package there (we should
> document the prerequisites better). Could you send the error message
>
There is no separate option, it should just work. :)
I'm betting you are still missing some package there (we should
document the prerequisites better). Could you send the error message
you are getting so we can have a look.
cheers,
pl
On 25 August 2015 at 16:20, Todd Fiala via lldb-dev
wrote:
On Mon, Aug 24, 2015 at 4:11 PM, Todd Fiala wrote:
>
>
> On Mon, Aug 24, 2015 at 4:01 PM, Chaoren Lin wrote:
>
>> The TestDataFormatterLibcc* tests require libc++-dev:
>>
>> $ sudo apt-get install libc++-dev
>>
>>
> Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
> Pre-14.
On Tue, Aug 25, 2015 at 5:40 AM, Tamas Berghammer
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 to be testing again
Thanks for the details on dosep.py, Dawn.
For counting I will probably go back to my old method of parsing the output
of a serial dotest run, since IIRC I can get skip counts accurately there
as well. (Or perhaps that should be added to dosep.py, it's been a while
since I last heavily modified th
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, but I think the rest of the tests
should pass (I wouldn't expect them to depend on libc++-dev).
You can see the
clang+llvm-3.7.0-rc3-mips-linux-gnu.tar.xz
All ok.
clang+llvm-3.7.0-rc3-mipsel-linux-gnu.tar.xz
All ok.
clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling for
Mips)
Still running the last few test-suite runs but no unexpected problems
so f
34 matches
Mail list logo
