With -Wl,--gc-sections defined.

RIOT/examples/hello-world@et-mbpr [add_gc] % make clean all BOARD=iot-lab_M3
...
   text    data     bss     dec     hex filename
   9528     112    3296   12936    3288 RIOT/examples/hello-world/bin/iot-lab_M3/hello-world.elf

Without -Wl,--gc-sections defined.

RIOT/examples/hello-world@et-mbpr [add_gc] % make clean all BOARD=iot-lab_M3
...
   text    data     bss     dec     hex filename
  12556     112    3296   15964    3e5c RIOT/examples/hello-world/bin/iot-lab_M3/hello-world.elf

+1
This is really useful on memory constrained systems like these, especially when combined with -ffunction-sections and -fdata-sections which are already included in CFLAGS on most (all?) RIOT platforms.

Yes, -ffunction-sections and -fdata-sections are defined for at least all cortex-m platforms. For these this PR also adds garbage collection. As mentioned in #723 some ARM7 platforms will need adaption of the linkerscript that's why they are not included here.

+1 here, too! I wonder how we best test this to find out if this could have any side-effects?

@haukepetersen, Like @thomaseichinger said, linker scripts must be adapted. If the linker script adds the object code with something like *(.text) and does not match wildcard *(.text.*) there will be a lot of errors about undefined references.

I guess one more side effect is that there may be unused code in the regression tests that does not trigger a build error wrt any undefined references (e.g. if a function or a global variable has changed name in an API change) since the unused functions are purged during the garbage collection, but this could also be seen as missing test coverage.

@gebart I didn't mean the Linkerscript part - that is quite clear. I was just wondering, if we might have problems from some code that is trying to use code that was dropped by the garbage collector? I actually can't think of any situation - but better think now then look for (hard to find) bugs later... :-)

@haukepetersen Well, if there is some code using parts of what is being dropped by the GC, then that would very likely be either: A linker bug, or the code is broken.

The only scenario that I can imagine where code would be using stuff without the actual symbol being detected as used would be if some address is hard coded and the address is used to access the data instead of the symbol itself.

I agree, I can not think of a standard case, where this would happen. So there is nothing speaking against merging this PR, right?

Needs rebase.

rebased

Add newer boards?

• airfy-beacon
• cc2538dk
• f4vi1
• fox
• openmote
• spark-core

@authmillenon I think we should decide if we go for this or #1927 first.

I think we go for #1927 for now and maybe include this later.

@thomaseichinger Could you rebase this on latest master?

Before merging this we need to verify that each of the modified platforms still produce working binaries. Some things to especially look for are:

• Garbage collected interrupt vector tables
• missing ISR handlers (if the above is OK, then this will probably not happen)
• Any hardware specific sections (e.g. the flash security memory segment on Kinetis devices) getting GC:ed
• missing ldscript *(.text.*) wildcard matches which may cause the binary to end up with 0 byte .text

@gebart rebased.

some size information on my test builds:

text    data    bss dec BOARD/BINDIRBASE

-11396  -296    -704    -12396  arduino-due
38460   2560    9936    50956   oldbin
27064   2264    9232    38560   bin

-11328  -292    -704    -12324  iot-lab_M3
55376   2568    9200    67144   oldbin
44048   2276    8496    54820   bin

-11440  -292    -700    -12432  msbiot
43928   2616    17192   63736   oldbin
32488   2324    16492   51304   bin

-11236  -296    -704    -12236  pca10000
38092   2552    4664    45308   oldbin
26856   2256    3960    33072   bin

-11236  -296    -704    -12236  pca10005
38060   2552    4664    45276   oldbin
26824   2256    3960    33040   bin

-19017  -296    -700    -20013  redbee-econotag
73689   2640    18712   95041   oldbin
54672   2344    18012   75028   bin

-13600  -292    -704    -14596  samr21-xpro
71504   2624    8512    82640   oldbin
57904   2332    7808    68044   bin

-11260  -296    -696    -12252  stm32f0discovery
39436   2552    3504    45492   oldbin
28176   2256    2808    33240   bin

-10804  -296    -704    -11804  stm32f3discovery
35852   2552    5120    43524   oldbin
25048   2256    4416    31720   bin

-10940  -296    -696    -11932  stm32f4discovery
36188   2560    9792    48540   oldbin
25248   2264    9096    36608   bin

-11396  -296    -704    -12396  udoo
38460   2560    9936    50956   oldbin
27064   2264    9232    38560   bin

-11236  -296    -704    -12236  yunjia-nrf51822
38052   2552    4664    45268   oldbin
26816   2256    3960    33032   bin

@gebart Does this compare to a normal compile or to a compilation using LTO?

And which application did you compile?

Normal compile of examples/default.

I created a list of all stripped symbols in the examples/default example, I don't have time to look through it right now and I don't have all the hardware to test these builds either.

Feel free to look through the list to see if any ISRs or other critical functions or variables have been stripped.

https://gist.github.com/gebart/252796588cce0b439f08

Can this be reviewed during the next Hack'n'ACK?

Like I wrote above, I don't have much of the hardware necessary to test this so it would be easier if people with the proper hardware can test this and report the results here rather than having to wade through all the stripped symbols list in order to find if anything crucial is missing.

The last Hack'n'ACK was yesterday (and I did not feel to have the expertise nor awareness to review this PR), so the next one would be in a month from now...

Tried it with the samr21 and the default application. My results:

   text    data     bss     dec     hex filename
  51128     224    8280   59632    e8f0 oldbin
  44484     224    8280   52988    cefc bin

And it ran just fine (i.e. I could use the usual shell commands and they worked). Not sure if that's a proper way to test this, though?

Maybe one can run a small test with rpl on IoT-LAB? If no one has the time, I can do next week. Please ping me.

ping @OlegHahm

Oops, I'm really sorry, but I forgot. Will try to do it today.

Seems not to break anything. ACK if rebased.

I will adopt this and rebase.

See #3163 for a rebase after the Cortex M unification