[libcxx] Add -fno-exceptions libcxx builders to zorg

[rmaprath]

Summary

This patch adds the necessary builders to zorg to get the -fno-exceptions libcxx library variant building. I've only used those build-slaves which I have got explicit permission to use for this purpose.

As discussed on the cfe-dev list, these builders won't run the libcxx test suite (they will, in the near future, when we adapt the tests).

These builders will ensure that we don't break the -fno-exceptions library build. This patch can only go in once D14292 is sorted.

[rmaprath]

PS: I've run a couple of hand-crafted builders on a locally hacked up buildbot and made sure the above changes are fine.

[gribozavr]

The Debian configuration LGTM.

[rengolin]

buildbot/osuosl/master/config/builders.py

868

I'd like to run this internally first, as I'm not sure it will work. I'll use this configuration and will let you know if it's ok.

We should only put this up if it's totally green.

[jroelofs]

buildbot/osuosl/master/config/builders.py

768

How bad is the fallout?

[rmaprath]

buildbot/osuosl/master/config/builders.py

768

I see about 160 test failures. Mostly because those tests have try/catch/throw statements that don't compile under -fno-exceptions, but there are other kinds of failures as well.

One option is to add xfails for those tests and gradually fix them up, this will ensure that we don't regress those tests that are already passing. I've taken the slightly more involved approach and started fixing the tests all in one go. I plan to send a follow-up patch soon with the general idea of the proposed "fix".

[rmaprath]

buildbot/osuosl/master/config/builders.py

868

Thanks! The newly added Debian configuration is quite similar to the configuration I ran locally. I have run some ARM configurations but it is best to run this particular configuration if possible.

You'd need the patch for D14292 though. I was hoping to get it committed first, so that these configs can be verified easily.

[rengolin]

Hi Asiri,

Can I propose a different approach?

We now have a silent buildbot, which will never email people about breakages, but can be publicly monitored by you, me and others. I'm assuming you have access to at least one x86 and one ARM machines, so that you could set up a local buildbot, reporting to the buildmaster, without upsetting anyone else, but where I, Jon, Marshall can also see the progress of all tests being fixed, thus helping approving the patches for future fixes.

You don't need to share any information on the board, just connect to the master and start building...

Once the bot is green, we can add the builds on our own public hardware, avoiding the need for disabling the tests.

cheers,
--renato

[rmaprath]

In D14293#280982, @rengolin wrote:

Hi Asiri,

Can I propose a different approach?

We now have a silent buildbot, which will never email people about breakages, but can be publicly monitored by you, me and others. I'm assuming you have access to at least one x86 and one ARM machines, so that you could set up a local buildbot, reporting to the buildmaster, without upsetting anyone else, but where I, Jon, Marshall can also see the progress of all tests being fixed, thus helping approving the patches for future fixes.

You don't need to share any information on the board, just connect to the master and start building...

Once the bot is green, we can add the builds on our own public hardware, avoiding the need for disabling the tests.

cheers,
--renato

Counter proposal, we mark all the currently failing (-fno-exceptions) test cases with:

// XFAIL: libcpp-no-exceptions

This has the following advantages:

• No need to change buildbots to skip tests
• The bots will catch any regressions in those tests that are already passing under -fno-exceptions
• You will be able to monitor my progress with the test fixes using the public (-fno-exceptions) buildbots
• I don't have to setup local buildbots (this is very difficult for us, infrastructure / legal problems)

What do you think?

• Asiri

[jroelofs]

Counter proposal, we mark all the currently failing (-fno-exceptions) test cases with:

// XFAIL: libcpp-no-exceptions

This has the following advantages:

• No need to change buildbots to skip tests
• The bots will catch any regressions in those tests that are already passing under -fno-exceptions
• You will be able to monitor my progress with the test fixes using the public (-fno-exceptions) buildbots
• I don't have to setup local buildbots (this is very difficult for us, infrastructure / legal problems)

What do you think?

I think this ^ is a reasonable solution.

Jon

• Asiri

[rengolin]

In D14293#281176, @jroelofs wrote:

I think this ^ is a reasonable solution.

I'm fine with that, as long as everyone's happy.

160 XFAILs are ok (as long as you're fixing them), disabling the tests makes no sense. :)

cheers,
--renato

[rmaprath]

In D14293#281183, @rengolin wrote:

In D14293#281176, @jroelofs wrote:

I think this ^ is a reasonable solution.

I'm fine with that, as long as everyone's happy.

160 XFAILs are ok (as long as you're fixing them), disabling the tests makes no sense. :)

cheers,
--renato

Great! I will update the patch D14292 to include the X-FAILS and then update the current patch to remove the hack which prevents the tests being run.

Thanks.

• Asiri

[rmaprath]

Updated patch to remove the skipping of tests. Now that we have the appropriate XFAILs in place, these two builders should be green.

I've locally tested the x86 run, I expect the ARM run to be fairly similar.

@Renato: could you kindly test this builder locally? Just in case.

Thanks.

• Asiri

[jroelofs]

buildbot/osuosl/master/config/builders.py

880

The order here seems a bit off to me. I think it should be:

lit_extra_opts={'link_flags': '"-lc++abi -lpthread -lunwind -ldl -lc -lm  -L/opt/llvm/lib/clang/3.6.0/lib/linux -lclang_rt.builtins-arm"'},

[rmaprath]

buildbot/osuosl/master/config/builders.py

880

@rengolin: If you are OK with Jon's suggestion, I can update both the configurations (I copied these lines from your existing A15 builder).

[rmaprath]

Would it be OK if I commit the x86 buildbot changes (Dmitri approved these earlier) while the ARM buildbot changes are being reviewed? I suppose the changes would only take effect once @gkistanova restarts/reconfigs the build-master ?

Cheers,

• Asiri

[jroelofs]

In D14293#287174, @rmaprath wrote:

Would it be OK if I commit the x86 buildbot changes (Dmitri approved these earlier) while the ARM buildbot changes are being reviewed? I suppose the changes would only take effect once @gkistanova restarts/reconfigs the build-master ?

Cheers,

• Asiri

That sounds reasonable to me. Be sure to notify Galina once you've made the change.

[rmaprath]

@rengolin: Gentle ping.

Cheers,

• Asiri

[rengolin]

Sorry, this fell out of my radar. I'm ok with the changes. Ping me when you commit so I can monitor the bot for a while.

[rmaprath]

In D14293#350570, @rengolin wrote:

Sorry, this fell out of my radar. I'm ok with the changes. Ping me when you commit so I can monitor the bot for a while.

Sorry, I missed your message this time around :)

I'll double-check the patch and commit. Thanks!

/ Asiri

buildbot/osuosl/master/config/builders.py

              env={'CC': 'clang', 'CXX': 'clang++'}),
          'category': 'libcxx'},
 
+        # x86_64 -fno-exceptions libcxx builder
+        {'name': 'libcxx-libcxxabi-x86_64-linux-debian-noexceptions',
+         'slavenames': ['gribozavr4'],
+         'builddir': 'libcxx-libcxxabi-x86_64-linux-debian-noexceptions',
+         'factory': LibcxxAndAbiBuilder.getLibcxxAndAbiBuilder(
+             env={'CC': 'clang', 'CXX': 'clang++'},
+             cmake_extra_opts={'LIBCXX_ENABLE_EXCEPTIONS': 'OFF'}),
+         'category': 'libcxx'},
+
         {'name': 'libcxx-libcxxabi-singlethreaded-x86_64-linux-debian',
          'slavenames': ['gribozavr4'],
          'builddir': 'libcxx-libcxxabi-singlethreaded-x86_64-linux-debian',

             cmake_extra_opts={'LIBCXXABI_USE_LLVM_UNWINDER': 'True',
                               'CMAKE_C_FLAGS': '-mcpu=cortex-a15',
                               'CMAKE_CXX_FLAGS': '-mcpu=cortex-a15'})},
+
+        # Cortex-A15 -fno-exceptions libcxx builder
+        {'name': 'libcxx-libcxxabi-arm-linux-noexceptions',
+         'slavenames': ['linaro-chrome-01'],
+         'builddir': 'libcxx-libcxxabi-arm-linux-noexceptions',
+         'category': 'libcxx',
+         'factory': LibcxxAndAbiBuilder.getLibcxxAndAbiBuilder(
+            env={'CC': 'clang', 'CXX': 'clang++'},
+            # FIXME: there should be a way to merge autodetected with user-defined linker flags
+            # See: libcxxabi/test/lit.cfg
+            lit_extra_opts={'link_flags': '"-lc++abi -lc -lm -lpthread -lunwind -ldl -L/opt/llvm/lib/clang/3.6.0/lib/linux -lclang_rt.builtins-arm"'},
+            cmake_extra_opts={'LIBCXXABI_USE_LLVM_UNWINDER': 'True',
+                              'CMAKE_C_FLAGS': '-mcpu=cortex-a15',
+                              'CMAKE_CXX_FLAGS': '-mcpu=cortex-a15',
+                              'LIBCXX_ENABLE_EXCEPTIONS': 'OFF'})},
     ]
 
 # Experimental and stopped builders