Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Empty program still links a lot of code making a rather heavy .hex
See original GitHub issueHi there!
Coming from the AVR world, I’ve recently started playing with ARM and mbed to my great pleasure. My way of exploring this new paradigm is to start from the examples, run them, tear them down until it stops working and build again one brick at a time to understand how things work together.
To start with, I’ve tried compiling an empty program int main(void) { return 0; }, expecting the resulting .hex to be close to empty.
But this is what I got:
$ mbed compile --stats-depth=10 --color -j8 --profile release
[mbed] Working path "/Users/ladislas/dev/leka/LKAlphaOS-mbed" (program)
[Warning] @,: Compiler version mismatch: Have 8.2.1; expected version >= 6.0.0 and < 7.0.0
Building project LKAlphaOS-mbed (NRF52_DK, GCC_ARM)
Scan: LKAlphaOS-mbed
Link: LKAlphaOS-mbed
Elf2Bin: LKAlphaOS-mbed
| Module | .text | .data | .bss |
|-------------------------------------------------------------------------------------------------------------------------|-----------|----------|---------|
| [fill] | 30(+0) | 4(+0) | 26(+0) |
| [lib]/c.a/lib_a-callocr.o | 96(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-ctype_.o | 0(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-dtoa.o | 3952(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-errno.o | 12(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-freer.o | 652(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-impure.o | 0(+0) | 1068(+0) | 0(+0) |
| [lib]/c.a/lib_a-init.o | 72(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-locale.o | 0(+0) | 364(+0) | 0(+0) |
| [lib]/c.a/lib_a-localeconv.o | 8(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-malloc.o | 16(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-mallocr.o | 1392(+0) | 1040(+0) | 52(+0) |
| [lib]/c.a/lib_a-mbtowc_r.o | 44(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-memchr.o | 160(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-memcpy.o | 308(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-memmove.o | 208(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-memset.o | 160(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-mprec.o | 1548(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-reallocr.o | 876(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-reent.o | 0(+0) | 0(+0) | 4(+0) |
| [lib]/c.a/lib_a-s_frexp.o | 112(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-sbrkr.o | 36(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-strlen.o | 220(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-strncpy.o | 116(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-svfiprintf.o | 248(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-svfprintf.o | 6724(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-vsnprintf.o | 136(+0) | 0(+0) | 0(+0) |
| [lib]/c.a/lib_a-wctomb_r.o | 28(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_aeabi_uldivmod.o | 48(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_arm_addsubdf3.o | 888(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_arm_cmpdf2.o | 272(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_arm_fixdfsi.o | 80(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_arm_muldivdf3.o | 1060(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_arm_unorddf2.o | 44(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_dvmd_tls.o | 4(+0) | 0(+0) | 0(+0) |
| [lib]/gcc.a/_udivmoddi4.o | 720(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crt0.o | 116(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crtbegin.o | 64(+0) | 4(+0) | 28(+0) |
| [lib]/misc/crtend.o | 0(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crti.o | 0(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crtn.o | 0(+0) | 0(+0) | 0(+0) |
| mbed-os/drivers/Serial.o | 54(+0) | 0(+0) | 0(+0) |
| mbed-os/drivers/UARTSerial.o | 20(+0) | 0(+0) | 0(+0) |
| mbed-os/hal/mbed_gpio.o | 88(+0) | 0(+0) | 0(+0) |
| mbed-os/hal/mbed_ticker_api.o | 950(+0) | 0(+0) | 0(+0) |
| mbed-os/hal/mbed_us_ticker_api.o | 64(+0) | 4(+0) | 65(+0) |
| mbed-os/platform/FileHandle.o | 4(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/TARGET_CORTEX_M/TOOLCHAIN_GCC/except.o | 204(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/TARGET_CORTEX_M/mbed_fault_handler.o | 380(+0) | 0(+0) | 84(+0) |
| mbed-os/platform/internal/mbed_atomic_impl.o | 72(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/mbed_alloc_wrappers.o | 16(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/mbed_board.o | 244(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/mbed_critical.o | 68(+0) | 0(+0) | 4(+0) |
| mbed-os/platform/mbed_error.o | 220(+0) | 0(+0) | 114(+0) |
| mbed-os/platform/mbed_retarget.o | 518(+0) | 260(+0) | 8(+0) |
| mbed-os/platform/mbed_sdk_boot.o | 30(+0) | 0(+0) | 0(+0) |
| mbed-os/platform/mbed_wait_api_no_rtos.o | 30(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/PeripheralPinsDefault.o | 0(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52832/device/TOOLCHAIN_GCC_ARM/startup_NRF52832.o | 296(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52832/device/cmsis_nvic.o | 16(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52832/device/system_nrf52.o | 716(+0) | 4(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/critical_section_api.o | 32(+0) | 1(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/flash_api.o | 0(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/gpio_api.o | 472(+0) | 0(+0) | 172(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/pinmap_ex.o | 108(+0) | 2(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/reloc_vector_table.o | 76(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/serial_api.o | 1748(+0) | 1(+0) | 203(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/us_ticker.o | 364(+0) | 0(+0) | 1(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/TARGET_SOFTDEVICE_NONE/nrf_soc_nosd/nrf_nvic.o | 52(+0) | 0(+0) | 1(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/components/libraries/atomic/nrf_atomic.o | 22(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/components/libraries/atomic_fifo/nrf_atfifo.o | 340(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/components/libraries/fds/fds.o | 1954(+0) | 0(+0) | 138(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/components/libraries/fstorage/nrf_fstorage.o | 168(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/components/libraries/util/app_util_platform.o | 8(+0) | 0(+0) | 0(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/modules/nrfx/drivers/src/nrfx_gpiote.o | 1540(+0) | 0(+0) | 76(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/modules/nrfx/drivers/src/nrfx_ppi.o | 240(+0) | 0(+0) | 4(+0) |
| mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_15_0/modules/nrfx/drivers/src/nrfx_rng.o | 44(+0) | 0(+0) | 4(+0) |
| src/main.o | 4(+0) | 0(+0) | 0(+0) |
| Subtotals | 31612(+0) | 2752(+0) | 984(+0) |
Total Static RAM memory (data + bss): 3736(+0) bytes
Total Flash memory (text + data): 34364(+0) bytes
Image: ./BUILD/NRF52_DK/GCC_ARM-RELEASE/LKAlphaOS-mbed.hex
This seems like a lot for an empty program… And I’m also surprised things like lib_a-dtoa.o are actually linked even if I’m only blinking a led or doing nothing at all.
As I said, I’m new to this, so maybe I’m doing something wrong, or maybe I missed the part in the documentation explaining why it’s this way.
Is this the expected behavior?
Thanks a lot for your time! 😃 Ladislas
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (2 by maintainers)
Top Results From Across the Web
Chapter 4, Compiling, Linking, and Locating - O'Reilly
After merging all of the code and data sections and resolving all of the symbol references, the linker produces an object file that...
Read more >[SOLVED] Programming empty chips: Best Practices? Guru ...
OBJECTIVE: be able to program empty microcontrollers in the most efficient and economical way. Hi... still very green here though ...
Read more >[Resolved] A few questions about self programming a PIC32
I want to add the ability to self update to my product and I have a few questions. 1. I assume that I...
Read more >Hex Dump In Many Programming Languages - C2 wiki
A new ProgrammingChrestomathy challenge: hexdump a file, given a starting and ending offset in the file, and number of bytes to display per...
Read more >How to represent hex value such as FFFFFFBB in x86 ...
I wanted to write mov ecx, FFFFFFBB , however the compiler isn't recognizing it. How should hex numbers like that be written in...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
A lot of work is being done in order to reduce the memory footprint. For example, Mbed OS 5.14 will provide a minimal printf library to replace the standard printf calls with a smaller implementation. This typically saves several tens of KB of Flash.
I’m not with ARM but since this is an open source project, we can use all the help we can get!
Looks like you already found bare-metal or your example is using it by default.
@0xc0170 any insight on code size reduction efforts?