Vendor (?) (STM32, EFM32, Kintetis, NRF, ...)

At least I thought I had kinetis in there :-/. @gebart any frdm board you prefer in that list or should I put mulle in there ;-)?

Murdock likes it :-)

@miri64 pick any kinetis board with a large number of FEATURES_PROVIDED. Mulle is one candidate, any of the frdm boards are also good.

Then I take mulle because it has 9, compared to the frdm's 8 ;-)

Rebased to current master and dependencies, added mulle to list of pre-selected boards.

Rebased to current master and dependencies, as #9808 was merged.

With #9821 it looks like I can correctly compile examples/javascript with llvm both on ubuntu 16.04 and in the docker image with BOARD=samr21-xpro.

Rebased to include current master and #9821.

Rebased to see if #9821 still fixes the jerryscript issues ;-)

Ooops, the fixes happened in #9824... Included as a new dependency.

Maybe a stacksize problem?

I was wrong... a crash is happening before, but in trying to print the thread state, it crashes again within hard_fault_handler again.

Maybe a stacksize problem?

Welp, I was able to pin it down on the thread_create() in gnrc_netif_create(), but when I just add one puts(), tests/gnrc_sixlowpan isn't failing anymore with LLVM:

diff --git a/sys/net/gnrc/netif/gnrc_netif.c b/sys/net/gnrc/netif/gnrc_netif.c
index 61a5cf5..79e6d87 100644
--- a/sys/net/gnrc/netif/gnrc_netif.c
+++ b/sys/net/gnrc/netif/gnrc_netif.c
@@ -1318,6 +1318,7 @@ static void *_gnrc_netif_thread(void *args)
 
     while (1) {
         DEBUG("gnrc_netif: waiting for incoming messages\n");
+        puts("");
         msg_receive(&msg);
         /* dispatch netdev, MAC and gnrc_netapi messages */
         switch (msg.type) {

Even

diff --git a/sys/net/gnrc/netif/gnrc_netif.c b/sys/net/gnrc/netif/gnrc_netif.c
index 61a5cf5..92377a7 100644
--- a/sys/net/gnrc/netif/gnrc_netif.c
+++ b/sys/net/gnrc/netif/gnrc_netif.c
@@ -1318,6 +1318,7 @@ static void *_gnrc_netif_thread(void *args)
 
     while (1) {
         DEBUG("gnrc_netif: waiting for incoming messages\n");
+        write(0, "", 0);
         msg_receive(&msg);
         /* dispatch netdev, MAC and gnrc_netapi messages */
         switch (msg.type) {

is enough to let the test pass oO.

Edit: fixed copy pasta

Could be an alignment problem. I suggest checking the objdump output.

Could be an alignment problem. I suggest checking the objdump output.

I don't even know what to look for there :-/

I added a fix that should fix the libc_newlib test. Basically, there is an issue to compare two function pointers… looks like some pointer optimization. The dedicated PR for reviewing it is #10014

I don't even know what to look for there :-/

Ok, with some LED toggling and clever puts() setting I was able to pin-point it on the fact that the dummy-device in the tests/gnrc_sixlowpan test isn't providing a link-layer address. While with GNU this doesn't seem to be necessary, LLVM seems to crash the system due to it. I'll try to figure out why.

(the behavior of the test is broken anyway, because the dummy device tells the application its address length is 8, but then when trying to get an address it returns -ENOTSUP, but I'd like to find out why this leads to a crash with LLVM regardless)

This is so weird... I applied the following patch:

diff --git a/sys/net/netdev_test/netdev_test.c b/sys/net/netdev_test/netdev_test.c
index 69883c1..0851d88 100644
--- a/sys/net/netdev_test/netdev_test.c
+++ b/sys/net/netdev_test/netdev_test.c
@@ -93,7 +93,9 @@ static int _get(netdev_t *netdev, netopt_t opt, void *value, size_t max_len)
     netdev_test_t *dev = (netdev_test_t *)netdev;
     int res = -ENOTSUP;     /* option assumed to be not supported */
 
+    puts(netopt2str(opt));
     mutex_lock(&dev->mutex);
+    puts("Ok");
     if (dev->get_cbs[opt] != NULL) {
         res = dev->get_cbs[opt](netdev, value, max_len);
     }

and compiled tests/gnrc_sixlowpan with LLVM. The output on samr21-xpro looks as follows:

2018-09-24 12:44:14,826 - INFO # main(): This is RIOT! (Version: 2018.10-devel-851-gfc32f-sarajevo)
2018-09-24 12:44:14,829 - INFO # RIOT network stack example application
2018-09-24 12:44:14,831 - INFO # NETOPT_DEVICE_TYPE
2018-09-24 12:44:14,831 - INFO # Ok
2018-09-24 12:44:14,833 - INFO # NETOPT_MAX_PACKET_SIZE
2018-09-24 12:44:14,834 - INFO # Ok
2018-09-24 12:44:14,835 - INFO # NETOPT_SRC_LEN
2018-09-24 12:44:14,835 - INFO # Ok
2018-09-24 12:44:14,837 - INFO # NETOPT_ADDRESS_LONG
2018-09-24 12:44:14,837 - INFO # Ok
2018-09-24 12:44:14,839 - INFO # NETOPT_IPV6_IID
2018-09-24 12:44:14,839 - INFO # 
2018-09-24 12:44:14,842 - INFO # Context before hardfault:

So it is to assume the node crashes when the mutex is locked for the IID. The call to the function with the provided output happens here

So it is only due to the previously mentioned fact, that this device is providing an address length but not an address, that we come to this point. It is strange nevertheless, that the node crashes at this point and the only reason I find logical is that the dev pointer might be wrong.

There is a fix for the link-layer address issue, but the crashing still happens in that test...

I'm pretty sure it doesn't happen in get() this time, however. I set LED_ON(0), when I enter the netdev_test:_get function and LED_OFF(0) when I leave it, but it is of at the point of crash.

It was a stack-size issue within the test after all -.-: #10024.

Rebased to current master and #10014

Rebased to current master.

Murdock should be happy with it now, but let's see.

Well the second fix happened in reaction to an issue with the first one and since they are of different authorship and address separate issues, they should stay distinct, so I say it's fine to merge them in that order.

LLVM support youhou !