tests/lwip: add blackpill to BOARD_INSUFFICIENT_MEMORY

[kaspar030]

Contribution description

Somehow this doesn't link on master anymore (test go too large), so blacklist it.

Testing procedure

make -Ctests/lwip BOARD=blackpill all fails on master, won't be built with this PR.

Issues/PRs references

Popped up e.g, here: https://ci.riot-os.org/RIOT-OS/RIOT/14205/3dea09894deea99e8a6739939e52799b680c2313/output/compile/tests/lwip/blackpill:gnu.txt

[kaspar030]

Somehow this doesn't link on master anymore (test go too large), so blacklist it.

this is very weird, a ccache clean on one of the workers solved the problem. This makes me loose quite some trust in ccache.

Anyhow, the test fits only by a small margin on the blackpill. With a newer gcc (like gcc 10.1 on arch) I cannot build anymore. Thus I suggest blacklisting now.

[fjmolinas]

Locally nucleo-f302r8 also fails for me :/

[fjmolinas]

Locally nucleo-f302r8 also fails for me :/

Also by around 1Kib

[kaspar030]

this is very weird, a ccache clean on one of the workers solved the problem. This makes me loose quite some trust in ccache.

I tracked it down to ccache turning absolute paths into relative, e.g.,

    1                                                            │    1                                                            
    2 ./lwip_api/api_msg.o:     file format elf32-littlearm      │    2 ./lwip_api/api_msg.o:     file format elf32-littlearm      
    3                                                            │    3                                                            
    4 Contents of section .text.sys_mbox_valid:                  │    4 Contents of section .text.sys_mbox_valid:                  
    5  0000 00690038 18bf0120 7047               .i.8... pG······│    5  0000 00690038 18bf0120 7047               .i.8... pG······
    6 Contents of section .rodata.recv_udp.str1.1:               │    6 Contents of section .rodata.recv_udp.str1.1:               
    7  0000 6170695f 6d73672e 63007265 63765f75  api_msg.c.recv_u│    7  0000 2f746d70 2f647771 2e302e39 37383837  /tmp/dwq.0.97887
    8  0010 6470206d 75737420 68617665 20612070  dp must have a p│    8  0010 30353533 36373032 3735332f 31653265  05536702753/1e2e
    9  0020 63622061 7267756d 656e7400 41737365  cb argument.Asse│    9  0020 34346466 31613563 38313061 66363739  44df1a5c810af679
   10  0030 7274696f 6e202225 73222066 61696c65  rtion "%s" faile│   10  0030 38633036 35316336 32653730 2f627569  8c0651c62e70/bui
   11  0040 64206174 2025733a 25640a00 72656376  d at %s:%d..recv│   11  0040 6c642f70 6b672f6c 7769702f 7372632f  ld/pkg/lwip/src/
   12  0050 5f756470 206d7573 74206861 76652061  _udp must have a│   12  0050 6170692f 6170695f 6d73672e 63007265  api/api_msg.c.re
   13  0060 6e206172 67756d65 6e740072 6563765f  n argument.recv_│   13  0060 63765f75 6470206d 75737420 68617665  cv_udp must have
   14  0070 7564703a 20726563 7620666f 72207772  udp: recv for wr│   14  0070 20612070 63622061 7267756d 656e7400   a pcb argument.
   15  0080 6f6e6720 70636221 00                 ong pcb!.·······│   15  0080 41737365 7274696f 6e202225 73222066  Assertion "%s" f
   16 Contents of section .text.recv_udp:                        │   16  0090 61696c65 64206174 2025733a 25640a00  ailed at %s:%d..
   17  0000 2de9f047 06461746 1c46bdf8 208039b9  -..G.F.F.F.. .9.│   17  00a0 72656376 5f756470 206d7573 74206861  recv_udp must ha
   18  0010 e5232e4a 2e492f48 fff7feff 002007e0  .#.J.I/H..... ..│   18  00b0 76652061 6e206172 67756d65 6e740072  ve an argument.r
   19  0020 50b9e623 294a2c49 2a48fff7 feff3046  P..#)J,I*H....0F│   19  00c0 6563765f 7564703a 20726563 7620666f  ecv_udp: recv fo
   20  0030 fff7feff fff7feff 43688b42 03d0ee23  ........Ch.B...#│   20  00d0 72207772 6f6e6720 70636221 00        r wrong pcb!.···

This are the objdump outputs of one of the files. I think the assertions include the filename.

[fjmolinas]

Can you add a comment on why we are blacklisting? pointing to the issue maybe that way if its fixed we can remove form the blacklist?

[kaspar030]

Can you add a comment on why we are blacklisting? pointing to the issue maybe that way if its fixed we can remove form the blacklist?

it is added to BOARD_INSUFFICIENT_MEMORY because it is too fat. it just happens to be so borderline that it sometimes actually fits (#14264).

Regular compiles (e.g., locally, even in docker container) that contain the full __FILE__ paths fail.

Not sure that justifies an extra comment?

[fjmolinas]

OK!

[fjmolinas]

ACK.