mbed cli vs mbed tools bin size comparision

[ladislas]

Description of defect

This is not really a defect but more of an observation.

Compiling the mbed-os-example-blinky with mbed cli and mbed tools gives very different results in terms of generated binary size. It's a big win for mbed tools. I'm wondering what's the reason for this.

mbed cli

mbed compile -m DISCO_F769NI -t GCC_ARM
[mbed] Working path "/Users/ladislas/dev/tmp/mbed-os-example-blinky" (program)
Building project mbed-os-example-blinky (DISCO_F769NI, GCC_ARM)
Scan: mbed-os-example-blinky
Link: mbed-os-example-blinky
Elf2Bin: mbed-os-example-blinky
| Module               |     .text |    .data |      .bss |
|----------------------|-----------|----------|-----------|
| [fill]               |   100(+0) |    3(+0) |    29(+0) |
| [lib]/c.a            |  4852(+0) | 2108(+0) |    89(+0) |
| [lib]/gcc.a          |   920(+0) |    0(+0) |     0(+0) |
| [lib]/misc           |   188(+0) |    4(+0) |    28(+0) |
| main.o               |    76(+0) |    0(+0) |     0(+0) |
| mbed-os/cmsis        |  9492(+0) |  168(+0) |  6212(+0) |
| mbed-os/connectivity |  2128(+0) |    0(+0) | 12796(+0) |
| mbed-os/drivers      |   150(+0) |    0(+0) |     0(+0) |
| mbed-os/events       |  1510(+0) |    0(+0) |  3104(+0) |
| mbed-os/hal          |  1696(+0) |    8(+0) |   130(+0) |
| mbed-os/platform     |  5460(+0) |  260(+0) |   424(+0) |
| mbed-os/rtos         |  1182(+0) |    0(+0) |     8(+0) |
| mbed-os/storage      |    36(+0) |    0(+0) |     4(+0) |
| mbed-os/targets      | 13418(+0) |    9(+0) |  1272(+0) |
| Subtotals            | 41208(+0) | 2560(+0) | 24096(+0) |
Total Static RAM memory (data + bss): 26656(+0) bytes
Total Flash memory (text + data): 43768(+0) bytes

Image: ./BUILD/DISCO_F769NI/GCC_ARM/mbed-os-example-blinky.bin

mbed tools

mbed-tools compile -t GCC_ARM -m DISCO_F769NI
Configuring project and generating build system...
-- The C compiler identification is GNU 9.3.1
-- The CXX compiler identification is GNU 9.3.1
[...]
-- built: /Users/ladislas/dev/tmp/mbed-os-example-blinky/cmake_build/mbed-os-example-blinky.bin
-- built: /Users/ladislas/dev/tmp/mbed-os-example-blinky/cmake_build/mbed-os-example-blinky.hex
| Module           |         .text |       .data |        .bss |
|------------------|---------------|-------------|-------------|
| [fill]           |       58(+58) |       4(+4) |     25(+25) |
| [lib]/c.a        |   4836(+4836) | 2108(+2108) |     89(+89) |
| [lib]/gcc.a      |     760(+760) |       0(+0) |       0(+0) |
| [lib]/misc       |     188(+188) |       4(+4) |     28(+28) |
| main.cpp.obj     |       76(+76) |       0(+0) |       0(+0) |
| mbed-os/cmsis    |   6970(+6970) |   168(+168) | 6208(+6208) |
| mbed-os/drivers  |     150(+150) |       0(+0) |       0(+0) |
| mbed-os/hal      |   1696(+1696) |       8(+8) |   130(+130) |
| mbed-os/platform |   5394(+5394) |   260(+260) |   424(+424) |
| mbed-os/rtos     |       28(+28) |       0(+0) |       0(+0) |
| mbed-os/targets  | 10680(+10680) |       8(+8) | 1272(+1272) |
| Subtotals        | 30836(+30836) | 2560(+2560) | 8176(+8176) |
Total Static RAM memory (data + bss): 10736(+10736) bytes
Total Flash memory (text + data): 33396(+33396) bytes

Target(s) affected by this defect ?

DISCO_F769NI

Toolchain(s) (name and version) displaying this defect ?

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

What version of Mbed-os are you using (tag or sha) ?

6.5.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed --version
1.10.4

mbed-tools --version
3.5.1.dev36

How is this defect reproduced ?

Compile mbed-os-example-blinky with mbed-cli and mbed-tools and compare the results.

[40Grit]

Hoping they call it mbed tools instead of mbed-cli-2 as announced.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2882

[0xc0170]

Hoping they call it mbed tools instead of mbed-cli-2 as announced.

Can you elaborate?

To the table above. We can see libs and main.cpp are almost identical. The difference is in the libraries. The table shows it, events or connectivity should not be in the blinky. The core libs have some differencies, I wonder about rtos as 28 bytes only ? The numbers might not be correct. We will review these numbers.

As we know linker is not always that clever (lto not yet enabled), therefore even some libraries not being used are still being pulled in to the final image. That is my experience.

cc @hugueskamba @rajkan01

[bulislaw]

@0xc0170 @hugueskamba

mbed compile -m DISCO_F769NI -t GCC_ARM

| Module               |     .text |    .data |      .bss |
|----------------------|-----------|----------|-----------|
| [fill]               |   100(+0) |    3(+0) |    29(+0) |
| [lib]/c.a            |  4852(+0) | 2108(+0) |    89(+0) |
| [lib]/gcc.a          |   920(+0) |    0(+0) |     0(+0) |
| [lib]/misc           |   188(+0) |    4(+0) |    28(+0) |
| main.o               |    76(+0) |    0(+0) |     0(+0) |
| mbed-os/cmsis        |  9492(+0) |  168(+0) |  6212(+0) |
| mbed-os/connectivity |  2128(+0) |    0(+0) | 12796(+0) |
| mbed-os/drivers      |   150(+0) |    0(+0) |     0(+0) |
| mbed-os/events       |  1510(+0) |    0(+0) |  3104(+0) |
| mbed-os/hal          |  1696(+0) |    8(+0) |   130(+0) |
| mbed-os/platform     |  5460(+0) |  260(+0) |   424(+0) |
| mbed-os/rtos         |  1182(+0) |    0(+0) |     8(+0) |
| mbed-os/storage      |    36(+0) |    0(+0) |     4(+0) |
| mbed-os/targets      | 13418(+0) |    9(+0) |  1272(+0) |
| Subtotals            | 41208(+0) | 2560(+0) | 24096(+0) |
Total Static RAM memory (data + bss): 26656(+0) bytes
Total Flash memory (text + data): 43768(+0) bytes

mbed-tools compile -t GCC_ARM -m DISCO_F769NI

| Module           |         .text |       .data |        .bss |
|------------------|---------------|-------------|-------------|
| [fill]           |       58(+58) |       4(+4) |     25(+25) |
| [lib]/c.a        |   4836(+4836) | 2108(+2108) |     89(+89) |
| [lib]/gcc.a      |     760(+760) |       0(+0) |       0(+0) |
| [lib]/misc       |     188(+188) |       4(+4) |     28(+28) |
| main.cpp.obj     |       76(+76) |       0(+0) |       0(+0) |
| mbed-os/cmsis    |   6970(+6970) |   168(+168) | 6208(+6208) |
| mbed-os/drivers  |     150(+150) |       0(+0) |       0(+0) |
| mbed-os/hal      |   1696(+1696) |       8(+8) |   130(+130) |
| mbed-os/platform |   5394(+5394) |   260(+260) |   424(+424) |
| mbed-os/rtos     |       28(+28) |       0(+0) |       0(+0) |
| mbed-os/targets  | 10680(+10680) |       8(+8) | 1272(+1272) |
| Subtotals        | 30836(+30836) | 2560(+2560) | 8176(+8176) |
Total Static RAM memory (data + bss): 10736(+10736) bytes
Total Flash memory (text + data): 33396(+33396) bytes

10K less is a good savings hopefully this is because old system pulled in junk not because the new one excludes something needed.

With current tools I can see things shouldn't be present in a blinky (connectivity??), but we should check two things:

• What's the detailed diff based on memory map and whether it's correct?
• What if I actually need the connectivity on this board (or similar) does the socket example pull in the right things?

[hugueskamba]

• What if I actually need the connectivity on this board (or similar) does the socket example pull in the right things?

The socket example should include the optional connectivity library (i.e CMake target) it requires to build.

[ladislas]

10K less is a good savings hopefully this is because old system pulled in junk not because the new one excludes something needed.

@bulislaw we've been using mbed-cmake for a few months now and already noticed the size difference (USCRPL/mbed-cmake#4)

We haven't add any issues with our project that is using more than just the blinky example: BLE, WIFI, SD, FileSystem, etc. -- all works perfectly well!

[ladislas]

We are currently in the process of moving from USCRPL/mbed-cmake to vanilla mbed-cmake, I'll let you know if we have any issues (already fixed one #13973)

[0xc0170]

Thanks for the feedback. I'll close this now. If there is anything we shall improve, lets create a new issue.