Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Sylvestre Ledru via lldb-dev]

What about creating a release management mailing list ?
The testers are usually the same (hello folks!) :)

Sylvestre

Le 20/01/2016 00:55, Hans Wennborg a écrit :
> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
>
> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>
>> There are still a bunch of open merge requests and bug reports, but I
>> wanted to get the tag in so we can see what the build and test status
>> are on the various platforms.
>>
>> I verified that it currently builds and tests cleanly for me on x86_64
>> Linux, Mac OS X* and Windows.
>>
>> Please build, test, and upload binaries to the sftp. Let me know if how it 
>> goes.
>>
>> Thanks,
>> Hans
>>
>>
>> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
>> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
>> otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
>> had to do this last time; maybe some upgrade changed something.

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

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Daniel Sanders via lldb-dev]

This isn't rc1 but the tip of the release branch had some X86 test failures on 
my most recent build:
Failing Tests (24):
libc++ :: 
std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
libc++ :: 
std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
libc++ :: 
std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
libc++ :: 
std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
libc++ :: 
std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
libc++ :: 
std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
libc++ :: 
std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
libc++ :: 
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
libc++ :: 
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
libc++ :: std/re/re.traits/default.pass.cpp
libc++ :: std/re/re.traits/getloc.pass.cpp
libc++ :: std/re/re.traits/imbue.pass.cpp
libomp :: barrier/omp_barrier.c

Big-endian mips gave this during phase 3:
CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
  Host Clang must be able to find libstdc++4.7 or newer!
It's possible that this is a machine config issue. We moved offices over the 
weekend (just across the street) and my normal machine somehow lost the ability 
to boot in the process. I'm borrowing a replacement at the moment.

Little-endian mips is just about to finish Phase 2 so I'll know if it's a more 
general problem soon.

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
> Of Hans Wennborg
> Sent: 19 January 2016 23:56
> To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian Cain;
> Renato Golin; Sylvestre Ledru
> Cc: cfe-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; llvm-dev
> Subject: Re: [3.8 Release] RC1 has been tagged
> 
> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
> 
> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg 
> wrote:
> > Dear testers,
> >
> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> > r258223. (It took a little longer than I'd planned, sorry about that.)
> >
> > There are still a bunch of open merge requests and bug reports, but I
> > wanted to get the tag in so we can see what the build and test status
> > are on the various platforms.
> >
> > I verified that it currently builds and tests cleanly for me on x86_64
> > Linux, Mac OS X* and Windows.
> >
> > Please build, test, and upload binaries to the sftp. Let me know if how it
> goes.
> >
> > Thanks,
> > Hans
> >
> >
> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
> > otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
> > had to do this last time; maybe some upgrade changed something.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Spurious process state change events

[Pavel Labath via lldb-dev]

Hello,

thanks for confirming my suspicions. Sending the extra running event
seems quite annoying to me as well, but it is how things work at the
moment. And the problem does not seem to be linux-specific. This is
the sequence of events I get on a Mac, when running over a conditional
breakpoint that does not stop:

Got event: running , restarted:  False
Got event: stopped , restarted:  True
Got event: running , restarted:  False
Got event: stopped , restarted:  False

Shall I file a bug about this?

pl

On 19 January 2016 at 19:03, Jim Ingham  wrote:
>
>> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev 
>>  wrote:
>>
>> +lldb-dev
>>
>> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:
>> Thanks, that was it!
>>
>> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
>> Hi,
>>
>> The stopped event should have the "restarted" flag set. You can use
>> the GetRestartedFromEvent function to check for that. (Let me know if
>> they don't). I think you can get this (under varying circumstances) on
>> other platforms as well, so you need to handle this everywhere.
>>
>> Somebody correct me if I'm wrong, but I believe that every restarted
>> should be then followed by a running event.
>
> No, if you get a stop event with the restarted bit set, the next event will 
> be another stop event.  It just seemed annoying, if you already know the 
> process restarted, to have to turn around and wait for the running event.
>
> Jim
>
>
>>
>> cheers,
>> pl
>>
>>
>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>>  wrote:
>> > Hi,
>> > I have a Python script that drives LLDB (in async mode), with a
>> > listener attached to the process.
>> > On OSX, upon the launch, LLDB emits a eStateRunning process state
>> > event, and then eventually eStateStopped - when a breakpoint is hit.
>> > On Linux, however, the initial eStateRunning is immediately followed
>> > by eStateStopped and another eStateRunning, without any intervention
>> > on my part.  This messes things up for me somewhat, because my script
>> > thinks that a breakpoint has been hit and tries examine state of the
>> > process.
>> > So I have 2 questions:
>> > - Is it supposed to happen?
>> > - What would be the best way to filter out these spurious stop events?
>> >   if is_linux and is_first_stop_event: ...  feels a bit hacky.
>> >
>> > thanks!
>> > ___
>> > 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] marking new summary output for expected timeouts

[Pavel Labath via lldb-dev]

Hi,

I have removed all of our expected timeouts from dosep.py (there are
still some freebsd and darwin ones left, but I don't know If anyone is
looking at those), so I think we're not using any part of the old test
runner at the moment. All clear for removal on our part.

pl


On 14 December 2015 at 16:06, Todd Fiala  wrote:
> Oh yeah, that's fine.  I won't take that code out.
>
> Hmm at least some of the builds went through this weekend, I made a number
> of changes Saturday morning (US Pacific time) that I saw go through the
> Ubuntu 14.04 cmake bot.
>
> On Mon, Dec 14, 2015 at 6:29 AM, Pavel Labath  wrote:
>>
>> Hi,
>>
>> we've had an unrelated breaking change, so the buildbots were red over
>> the weekend. I've fixed it now, and it seems to be turning green.
>> We've also had power outage during the weekend and not all of the
>> buildbots are back up yet, as we need to wait for MTV to wake up. I'd
>> like to give this at least one more day, to give them a chance to
>> stabilize. Is this blocking you from making further changes to the
>> test event system?
>>
>> pl
>>
>> On 12 December 2015 at 00:20, Todd Fiala  wrote:
>> > Hey Pavel and/or Tamas,
>> >
>> > Let me know when we're definitely all clear on the expected timeout
>> > support
>> > I added to the (now once again) newer default test results.
>> >
>> > As soon as we don't need the legacy summary results anymore, I'm going
>> > to
>> > strip out the code that manages it.  It is quite messy and duplicates
>> > the
>> > content that is better handled by the test event system.
>> >
>> > Thanks!
>> >
>> > -Todd
>> >
>> > On Fri, Dec 11, 2015 at 2:03 PM, Todd Fiala 
>> > wrote:
>> >>
>> >> I went ahead and added the expected timeout support in r255363.
>> >>
>> >> I'm going to turn back on the new BasicResultsFormatter as the default.
>> >> We can flip this back off if it is still not doing everything we need,
>> >> but I
>> >> *think* we cover the issue you saw now.
>> >>
>> >> -Todd
>> >>
>> >> On Fri, Dec 11, 2015 at 10:14 AM, Todd Fiala 
>> >> wrote:
>> >>>
>> >>> Hi Pavel,
>> >>>
>> >>> I'm going to adjust the new summary output for expected timeouts.  I
>> >>> hope
>> >>> to do that in the next hour or less.  I'll put that in and flip the
>> >>> default
>> >>> back on for using the new summary output.
>> >>>
>> >>> I'll do those two changes separately, so you can revert the flip back
>> >>> on
>> >>> to flip it back off if we still have an issue.
>> >>>
>> >>> Sound good?
>> >>>
>> >>> (This can be orthogonal to the new work to mark up expected timeouts).
>> >>> --
>> >>> -Todd
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> -Todd
>> >
>> >
>> >
>> >
>> > --
>> > -Todd
>
>
>
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have 
on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for 
general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can 
only disable libcxx, libcxxabi and libunwind together (maybe this can be 
improved)
* Last time I hand-built libcxx, it still had a lot of test failures in the 
locale parts, but I haven't had time to investigate.
* OpenMP does not support i386-freebsd, so I have to disable it there
* Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
last version that can build without C++11 support), and it crashes with a 
segfault during building of CGBlocks.cpp.  I'll need to find some way to work 
around this failure, since we cannot upgrade the compiler easily on FreeBSD 
10.x.

I also had to hack the test-release.sh script to fix a number of problems that 
I encountered during the 3.7.1 release, but haven't gotten to upstreaming them. 
 E.g. the way the source code is checked out with symlinks all over the place 
does not work, and I need to add a custom patch to clang-tools-extra to make 
the tests succeed, because there is a race condition in the Makefile.

-Dimitry

> On 20 Jan 2016, at 11:30, Daniel Sanders  wrote:
> 
> This isn't rc1 but the tip of the release branch had some X86 test failures 
> on my most recent build:
> Failing Tests (24):
>libc++ :: 
> std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
>libc++ :: 
> std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
>libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
>libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
>libc++ :: 
> std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
>libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
>libc++ :: 
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
>libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
>libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
>libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
>libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
>libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
>libc++ :: std/re/re.traits/default.pass.cpp
>libc++ :: std/re/re.traits/getloc.pass.cpp
>libc++ :: std/re/re.traits/imbue.pass.cpp
>libomp :: barrier/omp_barrier.c
> 
> Big-endian mips gave this during phase 3:
>   CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
> Host Clang must be able to find libstdc++4.7 or newer!
> It's possible that this is a machine config issue. We moved offices over the 
> weekend (just across the street) and my normal machine somehow lost the 
> ability to boot in the process. I'm borrowing a replacement at the moment.
> 
> Little-endian mips is just about to finish Phase 2 so I'll know if it's a 
> more general problem soon.
> 
>> -Original Message-
>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
>> Of Hans Wennborg
>> Sent: 19 January 2016 23:56
>> To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian Cain;
>> Renato Golin; Sylvestre Ledru
>> Cc: cfe-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; llvm-dev
>> Subject: Re: [3.8 Release] RC1 has been tagged
>> 
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>> 
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg 
>> wrote:
>>> Dear testers,
>>> 
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>> 
>>> There are still a bunch of open merge requests and bug reports, but I
>>> wanted to get the tag in so we can see what the build and test status
>>> are on the various platforms.
>>> 
>>> I verified tha

Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] We have branched

[Renato Golin via lldb-dev]

Hans, Daniel,

How are things going? It's been 5 days and no word. I'm running the
tests now, just in case, but would be good to know that no one would
be committing to the release candidate 1 tree in the mean time.

cheers,
--renato

On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
 wrote:
>> -Original Message-
>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
>> Of Hans Wennborg
>> Sent: 15 January 2016 15:52
>> To: Daniel Sanders
>> Cc: llvm-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; cfe-
>> d...@lists.llvm.org
>> Subject: Re: [cfe-dev] [3.8 Release] We have branched
>>
>> Hi Daniel,
>>
>> Thanks for trying out the branch :-)
>>
>> On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders
>>  wrote:
>> > Hi Hans,
>> >
>> > I tried the release branch last night and I'm having problems building it. 
>> > The
>> problem is that test-suite is now building as part of the Phase[123] builds
>> (because this project contains CMakeLists.txt's now) but cmake 3.0.2 (from
>> Debian Jessie) generates an invalid Makefile.
>> > The error is:
>> > CMakeFiles/test-suite.dir/build.make:112: *** target pattern 
>> > contains
>> no '%'.  Stop.
>> > CMakeFiles/Makefile2:199: recipe for target 'CMakeFiles/test-
>> suite.dir/all' failed
>> > And the referenced line of the generated makefile is:
>> > test-suite-stamps/test-suite-force-rebuild: /home/das-local/llvm-
>> release-3.8/release/branches_release_38/llvm.src/$
>> > it looks like cmake isn't fully expanding its generator expressions.
>> >
>> > Looking at my logs, it looks like the test-suite used to configure in 
>> > 3.6.2 but
>> didn't build as part of test-release.sh and then 3.7.0 stopped since we had
>> switched to cmake and there was no CMakeLists.txt.
>> > I've always run the test-suite as a separate step as described in
>> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the
>> projects/test-suite symlink to get back to the behaviour from 3.7.0 or should
>> we do something else?
>>
>> Yes, I made the script stop making the symlink in r257791 and merged
>> it to the branch. Did that not work for you, or were you at an earlier
>> revision?
>>
>> Thanks,
>> Hans
>
> I'm at r257773 so it looks like I didn't pick up that change. I'll give it 
> another try tonight.
>
> Thanks
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] We have branched

[Daniel Sanders via lldb-dev]

Sorry for not replying back on this thread. We moved offices over the weekend 
and I've been busy sorting various things out.

I'm currently building rc1 but my most recent build on the release branch had 
some regressions. I mentioned them on the rc1 thread but to summarize here:
* X86 failed ~20 libc++ tests and 1 libomp test
* Big-endian mips fails to configure phase 3. It reports errors about being 
unable to find libstdc++4.7 or newer. I've just resurrected the machine that 
normally does this build (it died during the move) so I'll start rc1 on it 
finishes the buildbot builds that have accumulated.
* Little-endian mips is still building (I had to move the machine and restart 
the build) but it's got further than big-endian.

> -Original Message-
> From: Renato Golin [mailto:renato.go...@linaro.org]
> Sent: 20 January 2016 15:33
> To: Daniel Sanders
> Cc: Hans Wennborg; llvm-dev; cfe-...@lists.llvm.org; openmp-
> d...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [llvm-dev] [cfe-dev] [3.8 Release] We have branched
> 
> Hans, Daniel,
> 
> How are things going? It's been 5 days and no word. I'm running the
> tests now, just in case, but would be good to know that no one would
> be committing to the release candidate 1 tree in the mean time.
> 
> cheers,
> --renato
> 
> On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
>  wrote:
> >> -Original Message-
> >> From: hwennb...@google.com [mailto:hwennb...@google.com] On
> Behalf
> >> Of Hans Wennborg
> >> Sent: 15 January 2016 15:52
> >> To: Daniel Sanders
> >> Cc: llvm-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; cfe-
> >> d...@lists.llvm.org
> >> Subject: Re: [cfe-dev] [3.8 Release] We have branched
> >>
> >> Hi Daniel,
> >>
> >> Thanks for trying out the branch :-)
> >>
> >> On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders
> >>  wrote:
> >> > Hi Hans,
> >> >
> >> > I tried the release branch last night and I'm having problems building 
> >> > it.
> The
> >> problem is that test-suite is now building as part of the Phase[123] builds
> >> (because this project contains CMakeLists.txt's now) but cmake 3.0.2
> (from
> >> Debian Jessie) generates an invalid Makefile.
> >> > The error is:
> >> > CMakeFiles/test-suite.dir/build.make:112: *** target pattern
> contains
> >> no '%'.  Stop.
> >> > CMakeFiles/Makefile2:199: recipe for target 'CMakeFiles/test-
> >> suite.dir/all' failed
> >> > And the referenced line of the generated makefile is:
> >> > test-suite-stamps/test-suite-force-rebuild: /home/das-local/llvm-
> >> release-
> 3.8/release/branches_release_38/llvm.src/$
> >> > it looks like cmake isn't fully expanding its generator expressions.
> >> >
> >> > Looking at my logs, it looks like the test-suite used to configure in 
> >> > 3.6.2
> but
> >> didn't build as part of test-release.sh and then 3.7.0 stopped since we had
> >> switched to cmake and there was no CMakeLists.txt.
> >> > I've always run the test-suite as a separate step as described in
> >> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the
> >> projects/test-suite symlink to get back to the behaviour from 3.7.0 or
> should
> >> we do something else?
> >>
> >> Yes, I made the script stop making the symlink in r257791 and merged
> >> it to the branch. Did that not work for you, or were you at an earlier
> >> revision?
> >>
> >> Thanks,
> >> Hans
> >
> > I'm at r257773 so it looks like I didn't pick up that change. I'll give it 
> > another
> try tonight.
> >
> > Thanks
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Ben Pope via lldb-dev]

On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

There are still a bunch of open merge requests and bug reports, but I
wanted to get the tag in so we can see what the build and test status
are on the various platforms.

I verified that it currently builds and tests cleanly for me on x86_64
Linux, Mac OS X* and Windows.

Please build, test, and upload binaries to the sftp. Let me know if how it goes.


Some issues:

LNT didn't finish: perhaps my checkout is incomplete, this bit seems to 
have changed with the switch to cmake.  Some unexpected failures on 
Ubuntu 14.04, but 15.10 was great.


LNT:
nt.py:499: fatal error: unable to import test module: 
'3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'

Traceback (most recent call last):
  File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in 
execute_test_modules

exec module_file in locals, globals
  File 
"3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule", 
line 4, in 

import spec
ImportError: No module named spec

Ubuntu 14.04 x86_64:
Failing Tests (14):
AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
MemorySanitizer :: Linux/forkpty.cc
MemorySanitizer :: Linux/tcgetattr.cc
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r

Profile :: instrprof-error.c
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
libc++ :: 
std/localization/locales/locale/locale.cons/char_pointer.pass.cpp


  Expected Passes: 31165
  Expected Failures  : 195
  Unsupported Tests  : 527
  Unexpected Failures: 14

Ubuntu 15.10 x86_64:
  Expected Passes: 31838
  Expected Failures  : 209
  Unsupported Tests  : 649

Uploaded:
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

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

Re: [lldb-dev] Spurious process state change events

[Jim Ingham via lldb-dev]

Please do file a bug, that's definitely not how things are supposed to work.  
You will still see a private "running" event, of course, since those are just 
the raw events from the target, but the running event shouldn't get broadcast 
to the public event queue if it was coming from a continuation due to a 
breakpoint condition or command.

Jim


> On Jan 20, 2016, at 3:59 AM, Pavel Labath  wrote:
> 
> Hello,
> 
> thanks for confirming my suspicions. Sending the extra running event
> seems quite annoying to me as well, but it is how things work at the
> moment. And the problem does not seem to be linux-specific. This is
> the sequence of events I get on a Mac, when running over a conditional
> breakpoint that does not stop:
> 
> Got event: running , restarted:  False
> Got event: stopped , restarted:  True
> Got event: running , restarted:  False
> Got event: stopped , restarted:  False
> 
> Shall I file a bug about this?
> 
> pl
> 
> On 19 January 2016 at 19:03, Jim Ingham  wrote:
>> 
>>> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev 
>>>  wrote:
>>> 
>>> +lldb-dev
>>> 
>>> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:
>>> Thanks, that was it!
>>> 
>>> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
>>> Hi,
>>> 
>>> The stopped event should have the "restarted" flag set. You can use
>>> the GetRestartedFromEvent function to check for that. (Let me know if
>>> they don't). I think you can get this (under varying circumstances) on
>>> other platforms as well, so you need to handle this everywhere.
>>> 
>>> Somebody correct me if I'm wrong, but I believe that every restarted
>>> should be then followed by a running event.
>> 
>> No, if you get a stop event with the restarted bit set, the next event will 
>> be another stop event.  It just seemed annoying, if you already know the 
>> process restarted, to have to turn around and wait for the running event.
>> 
>> Jim
>> 
>> 
>>> 
>>> cheers,
>>> pl
>>> 
>>> 
>>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>>>  wrote:
 Hi,
 I have a Python script that drives LLDB (in async mode), with a
 listener attached to the process.
 On OSX, upon the launch, LLDB emits a eStateRunning process state
 event, and then eventually eStateStopped - when a breakpoint is hit.
 On Linux, however, the initial eStateRunning is immediately followed
 by eStateStopped and another eStateRunning, without any intervention
 on my part.  This messes things up for me somewhat, because my script
 thinks that a breakpoint has been hit and tries examine state of the
 process.
 So I have 2 questions:
 - Is it supposed to happen?
 - What would be the best way to filter out these spurious stop events?
  if is_linux and is_first_stop_event: ...  feels a bit hacky.
 
 thanks!
 ___
 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] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

That would certainly make my emails easier to address :-) On the other
hand, I do think there's a point to asking for testers each time and
then only addressing those that sign up explicitly. What do the rest
of you think about having a list?

On Wed, Jan 20, 2016 at 1:31 AM, Sylvestre Ledru  wrote:
> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
>
> Sylvestre
>
> Le 20/01/2016 00:55, Hans Wennborg a écrit :
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>>
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
>>> Dear testers,
>>>
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>>> r258223. (It took a little longer than I'd planned, sorry about that.)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 2:15 AM, Ismail Donmez  wrote:
> On Wed, Jan 20, 2016 at 1:47 AM, Hans Wennborg via cfe-dev
>  wrote:
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>
>> There are still a bunch of open merge requests and bug reports, but I
>> wanted to get the tag in so we can see what the build and test status
>> are on the various platforms.
>>
>> I verified that it currently builds and tests cleanly for me on x86_64
>> Linux, Mac OS X* and Windows.
>
> Doesn't looks good here, stage2 build crashes:

:-(

Can you file a bug with the preprocessed source and invocation attached?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric  wrote:
> Unfortunately I'm having lots of trouble with rc1 at this point:
> * libcxxabi can't build, because it requires unwind.h, which we do not yet 
> have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not 
> ready for general consumption).
> * The test-release.sh script has no option to disable only libcxxabi, you can 
> only disable libcxx, libcxxabi and libunwind together (maybe this can be 
> improved)

Yes, I'd be happy to take a patch for this, or I suppose you could
just hack it out locally when building.

> * Last time I hand-built libcxx, it still had a lot of test failures in the 
> locale parts, but I haven't had time to investigate.

Did we have that for 3.7 too?

> * OpenMP does not support i386-freebsd, so I have to disable it there

That's perfectly fine. Including OpenMP by default is new for this
release, so if it causes any problems, just exclude it.

> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
> last version that can build without C++11 support), and it crashes with a 
> segfault during building of CGBlocks.cpp.  I'll need to find some way to work 
> around this failure, since we cannot upgrade the compiler easily on FreeBSD 
> 10.x.

This sounds like the biggest problem. Is there a PR for the crash? I
suppose the alternatives are either to try not to tickle the crash in
our source, or fixing the 3.4.1 compiler?

> I also had to hack the test-release.sh script to fix a number of problems 
> that I encountered during the 3.7.1 release, but haven't gotten to 
> upstreaming them.  E.g. the way the source code is checked out with symlinks 
> all over the place does not work, and I need to add a custom patch to 
> clang-tools-extra to make the tests succeed, because there is a race 
> condition in the Makefile.

:-( What's not working with the symlinks? Please send patches. I'm
sorry for the trouble here.

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

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope  wrote:
> On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:
>>
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)

> Some issues:
>
> LNT didn't finish: perhaps my checkout is incomplete, this bit seems to have
> changed with the switch to cmake.  Some unexpected failures on Ubuntu 14.04,
> but 15.10 was great.

How did you build LNT? I think previously it used to get configured
automatically, but not built. Recently someone added a cmake file to
it, which didn't work, so I excluded it from the test-release build in
r257791

>
> LNT:
> nt.py:499: fatal error: unable to import test module:
> '3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'
> Traceback (most recent call last):
>   File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in
> execute_test_modules
> exec module_file in locals, globals
>   File
> "3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule",
> line 4, in 
> import spec
> ImportError: No module named spec
>
> Ubuntu 14.04 x86_64:
> Failing Tests (14):
> AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
> Profile :: instrprof-error.c
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
> libc++ ::
> std/localization/locales/locale/locale.cons/char_pointer.pass.cpp

Weird. These all passed for me on 14.04.

>
> Uploaded:
> clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

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

[lldb-dev] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

I'm trying to get the lldb tests running using lldb built with Hexagon
support. Some tests are running correctly, but others are failing/skipped
etc. 

 

First, I'd like to get it to skip tests that shouldn't be run. For example,
I see output that looks like this:

Configuration: arch=x86_64
compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin
/hexagon-clang

 

Or

 

Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tool
s/bin/hexagon-clang

 

Those are clearly incorrect. 

 

My dotest line is:

python dotest.py -C
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-
clang --executable /local/mnt/workspace/ted/8.0/build/bin/lldb

 

How does the -A flag affect the Configuration/Config outputs above?

 

Ted

 

--

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] [llvm-dev] [cfe-dev] [3.8 Release] We have branched

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 7:32 AM, Renato Golin  wrote:
> Hans, Daniel,
>
> How are things going? It's been 5 days and no word. I'm running the
> tests now, just in case, but would be good to know that no one would
> be committing to the release candidate 1 tree in the mean time.

Did you send this before I sent the rc1 email, or what things are you
referring to? :-)




> On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
>  wrote:
>>> -Original Message-
>>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
>>> Of Hans Wennborg
>>> Sent: 15 January 2016 15:52
>>> To: Daniel Sanders
>>> Cc: llvm-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; cfe-
>>> d...@lists.llvm.org
>>> Subject: Re: [cfe-dev] [3.8 Release] We have branched
>>>
>>> Hi Daniel,
>>>
>>> Thanks for trying out the branch :-)
>>>
>>> On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders
>>>  wrote:
>>> > Hi Hans,
>>> >
>>> > I tried the release branch last night and I'm having problems building 
>>> > it. The
>>> problem is that test-suite is now building as part of the Phase[123] builds
>>> (because this project contains CMakeLists.txt's now) but cmake 3.0.2 (from
>>> Debian Jessie) generates an invalid Makefile.
>>> > The error is:
>>> > CMakeFiles/test-suite.dir/build.make:112: *** target pattern 
>>> > contains
>>> no '%'.  Stop.
>>> > CMakeFiles/Makefile2:199: recipe for target 'CMakeFiles/test-
>>> suite.dir/all' failed
>>> > And the referenced line of the generated makefile is:
>>> > test-suite-stamps/test-suite-force-rebuild: /home/das-local/llvm-
>>> release-3.8/release/branches_release_38/llvm.src/$
>>> > it looks like cmake isn't fully expanding its generator expressions.
>>> >
>>> > Looking at my logs, it looks like the test-suite used to configure in 
>>> > 3.6.2 but
>>> didn't build as part of test-release.sh and then 3.7.0 stopped since we had
>>> switched to cmake and there was no CMakeLists.txt.
>>> > I've always run the test-suite as a separate step as described in
>>> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the
>>> projects/test-suite symlink to get back to the behaviour from 3.7.0 or 
>>> should
>>> we do something else?
>>>
>>> Yes, I made the script stop making the symlink in r257791 and merged
>>> it to the branch. Did that not work for you, or were you at an earlier
>>> revision?
>>>
>>> Thanks,
>>> Hans
>>
>> I'm at r257773 so it looks like I didn't pick up that change. I'll give it 
>> another try tonight.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Getting lldb tests working on Hexagon

[Zachary Turner via lldb-dev]

If it should never run with x86_64 on Hexagon, then don't bother using
command lines, just change dotest.py so that when the target is hexagon,
the default archs doesn't include x86_64

On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For
> example, I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> 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] Getting lldb tests working on Hexagon

[Pavel Labath via lldb-dev]

What is the sequence of lldb commands you use to innitiate a hexagon
debug session normally? Do you need to set a custom platform (platform
select XXX)? If so, then you need to look into --platform-name (and
possibly --platform-url, --platform-working-dir) parameter, and
possibly add some support there?

On 20 January 2016 at 17:48, Ted Woodward via lldb-dev
 wrote:
> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For example,
> I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> 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] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

A Hexagon debug session connects to the Hexagon simulator. lldb launches 
hexagon-sim in the same way it launches lldb-server or debugserver.

When a Hexagon target is loaded, lldb automatically selects the hexagon 
platform.

So, no special settings - target create, set a breakpoint, run.

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

-Original Message-
From: Pavel Labath [mailto:lab...@google.com] 
Sent: Wednesday, January 20, 2016 12:07 PM
To: Ted Woodward
Cc: LLDB
Subject: Re: [lldb-dev] Getting lldb tests working on Hexagon

What is the sequence of lldb commands you use to innitiate a hexagon debug 
session normally? Do you need to set a custom platform (platform select XXX)? 
If so, then you need to look into --platform-name (and possibly --platform-url, 
--platform-working-dir) parameter, and possibly add some support there?

On 20 January 2016 at 17:48, Ted Woodward via lldb-dev 
 wrote:
> I’m trying to get the lldb tests running using lldb built with Hexagon 
> support. Some tests are running correctly, but others are 
> failing/skipped etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For 
> example, I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Too
> ls/bin/hexagon-clang
>
>
>
> Or
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/lates
> t/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/he
> xagon-clang --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> 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] Getting lldb tests working on Hexagon

[Ted Woodward via lldb-dev]

 

Where are the default archs defined? I’m not seeing it, looking through 
testcases/dotest.py.

 

--

Qualcomm Innovation Center, Inc.

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

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Wednesday, January 20, 2016 11:55 AM
To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] Getting lldb tests working on Hexagon

 

If it should never run with x86_64 on Hexagon, then don't bother using command 
lines, just change dotest.py so that when the target is hexagon, the default 
archs doesn't include x86_64

 

On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

I’m trying to get the lldb tests running using lldb built with Hexagon support. 
Some tests are running correctly, but others are failing/skipped etc. 

 

First, I’d like to get it to skip tests that shouldn’t be run. For example, I 
see output that looks like this:

Configuration: arch=x86_64 
compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang

 

Or

 

Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang

 

Those are clearly incorrect. 

 

My dotest line is:

python dotest.py -C 
/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
 --executable /local/mnt/workspace/ted/8.0/build/bin/lldb

 

How does the –A flag affect the Configuration/Config outputs above?

 

Ted

 

--

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] Getting lldb tests working on Hexagon

[Zachary Turner via lldb-dev]

Apparently I'm dumb, you actually should specify archs.  For example, on
Windows we use --arch=i686

If you don't specify a value for --arch, it uses the result of
`platform.machine()`.  If you do, it uses the list that you specify.  So
basically if you say --arch=i386 or something like, it will use that
instead of x86_64.

On Wed, Jan 20, 2016 at 10:56 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> Where are the default archs defined? I’m not seeing it, looking through
> testcases/dotest.py.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Wednesday, January 20, 2016 11:55 AM
> *To:* Ted Woodward; LLDB
>
>
> *Subject:* Re: [lldb-dev] Getting lldb tests working on Hexagon
>
>
>
> If it should never run with x86_64 on Hexagon, then don't bother using
> command lines, just change dotest.py so that when the target is hexagon,
> the default archs doesn't include x86_64
>
>
>
> On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For
> example, I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jan 2016, at 18:23, Hans Wennborg  wrote:
> 
> On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric  wrote:
>> Unfortunately I'm having lots of trouble with rc1 at this point:
>> * libcxxabi can't build, because it requires unwind.h, which we do not yet 
>> have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not 
>> ready for general consumption).
>> * The test-release.sh script has no option to disable only libcxxabi, you 
>> can only disable libcxx, libcxxabi and libunwind together (maybe this can be 
>> improved)
> 
> Yes, I'd be happy to take a patch for this, or I suppose you could
> just hack it out locally when building.

It's not terribly important right now, as libcxx isn't succeeding its tests 
anyway.  I can locally hack it in, but I hope I won't forget it later. :)


>> * Last time I hand-built libcxx, it still had a lot of test failures in the 
>> locale parts, but I haven't had time to investigate.
> 
> Did we have that for 3.7 too?

With 3.7, we used autoconf builds for FreeBSD, and that skipped libcxx 
altogether.  I did a few builds by hand, and I remember I saw similar failures. 
 This is just something that nobody (from FreeBSD) has seriously looked at, and 
I never had the time for it.  There are only so much hours in a day...

For example, recently with trunk r256945, I saw these:

Failing Tests (39):
libc++ :: std/depr/depr.c.headers/stddef_h.pass.cpp
libc++ :: std/depr/depr.c.headers/wchar_h.pass.cpp
libc++ :: std/language.support/support.types/max_align_t.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
libc++ :: 
std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_1.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp
libc++ :: 
std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
libc++ :: 
std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_date.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_date_wide.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
libc++ :: 
std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
libc++ :: 
std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
libc++ :: 
std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp
libc++ :: std/re/re.traits/lookup_collatename.pass.cpp
libc++ :: std/re/re.traits/transform_primary.pass.cpp
libc++ :: std/re/re.traits/translate_nocase.pass.cpp
libc++ :: std/strings/string.conversions/stof.pass.cpp
libc++ :: 
std/utilities/

Re: [lldb-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric  wrote:
> As to the symlinks, the test-release.sh script originally checks out the 
> sources in parallel directories, e.g.:
>
> llvm.src
> cfe.src
> compiler-rt.src
>
> and so on.  Within llvm.src, symlinks are made to point to each of these.  
> For some reason, on FreeBSD, this causes .cpp files under 
> llvm.src/tools/clang/tools/extra to not be able to find their include files, 
> and my log files show the following kind of errors:
>
> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10:
>  fatal error: 'clang/Tooling/Refactoring.h' file not found
> #include "clang/Tooling/Refactoring.h"
>  ^
> 1 error generated.
>
> I remember trying lots of things to make this work, but failing.  Apparently 
> there is some issue with following a double symlink path, e.g. 
> llvm.src/tools/clang is a symlink to ../../cfe.src, while 
> llvm.src/tools/clang/tools/extra (which really is under ../../cfe.src/tools) 
> is a symlink to ../../clang-tools-extra.src.

Oh, I thought it was a CMake vs. autoconf thing, and we were just
symlinking clang-tools-extra wrong (see r257905). I guess I jumped to
wrong conclusions there :-/

> The way I fixed this during the 3.7 test phase, is by changing 
> test-release.sh so it exports directly into these locations:
>
> # Exporting llvm 3.7.0-rc3 sources to llvm.src
> # Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
> # Exporting clang-tools-extra 3.7.0-rc3 sources to 
> llvm.src/tools/clang/tools/extra
> # Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
> # Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
> # Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
> # Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
> # Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite
>
> This is probably not so handy if you want to create tarballs of the 
> individual components, though.

Actually, I use export.sh for creating the tarballs, so that's not a
problem. Maybe just exporting into the right directories is the way to
go.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev