After turning on CONFIG_HEAP_MEM_POOL_SIZE, zephyr.bin becomes much larger

[foxriver1025]

In my prj.conf, I config HEAP_MEM_POOL_SEZE like this:
CONFIG_HEAP_MEM_POOL_SIZE=4194304
I found that the zephyr.bin file finally became about 4M in size.
The Section header is as belows:

[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] rom_start         PROGBITS        7c010000 0000a0 000060 00  AX  0   0  4
  [ 2] reset             PROGBITS        7c010060 000100 000006 00  AX  0   0  4
  [ 3] exceptions        PROGBITS        7c010068 000108 00013a 00  AX  0   0  4
  [ 4] text              PROGBITS        7c0101a4 000244 00251c 00  AX  0   0  4
  [ 5] initlevel         PROGBITS        7c0126c0 002760 000020 00   A  0   0  4
  [ 6] device_area       PROGBITS        7c0126e0 002780 000014 00   A  0   0  4
  [ 7] sw_isr_table      PROGBITS        7c0126f4 002794 000200 00  WA  0   0  4
  [ 8] rodata            PROGBITS        7c0128f4 002994 0002c0 00   A  0   0  4
  [ 9] bss               NOBITS          7c012bb8 002c54 000190 00  WA  0   0  8
  [10] noinit            NOBITS          7c012d50 002c54 400b00 00  WA  0   0 16
  [11] datas             PROGBITS        7c413850 002c54 000020 00  WA  0   0  4
  [12] device_states     PROGBITS        7c413870 002c74 000002 00  WA  0   0  1
  [13] k_heap_area       PROGBITS        7c413874 002c78 000014 00  WA  0   0  4
  [14] .comment          PROGBITS        00000000 002c8c 00003b 01  MS  0   0  1
  [15] .debug_aranges    PROGBITS        00000000 002cc8 000b18 00      0   0  8
  [16] .debug_info       PROGBITS        00000000 0037e0 020217 00      0   0  1
  [17] .debug_abbrev     PROGBITS        00000000 0239f7 00567f 00      0   0  1
  [18] .debug_line       PROGBITS        00000000 029076 0134e0 00      0   0  1
  [19] .debug_frame      PROGBITS        00000000 03c558 001924 00      0   0  4
  [20] .debug_str        PROGBITS        00000000 03de7c 004757 01  MS  0   0  1
  [21] .debug_loc        PROGBITS        00000000 0425d3 00b4ee 00      0   0  1
  [22] .debug_ranges     PROGBITS        00000000 04dac8 002e78 00      0   0  8
  [23] .riscv.attributes RISCV_ATTRIBUTE 00000000 050940 000035 00      0   0  1
  [24] .symtab           SYMTAB          00000000 050978 0025f0 10     25 135  4
  [25] .strtab           STRTAB          00000000 052f68 002f66 00      0   0  1
  [26] .shstrtab         STRTAB          00000000 055ece 000111 00      0   0  1

The three segments datas, device_states, and k_heap_area were placed at the end of the memory, and the memory holes were filled with 0xff, causing the final bin to become larger.
Because the memory is dynamically allocated, I don't want the bin file to become larger. Is there any way to solve this problem?

[yashi]

CONFIG_HEAP_MEM_POOL_SIZE is for the system heap and it's initialized at build time. Thus, must be in data section. If your application need a heap from BSS, allocate a region in BSS and call k_heap_init() on it.

[yashi]

@fkokosinski @kgugala @tgorochowik
Wouldn't it be better if we could fix this upstream?

[fkokosinski]

@yashi yup, if RISC-V binary sizes differ significantly from other archs, then that would be the right way to go.

Though @foxriver1025 I tried to recreate what @yashi did for qemu_cortex_a9 but with qemu_riscv64, and:

% west build -p -b qemu_riscv64 samples/hello_world -- -DCONFIG_HEAP_MEM_POOL_SIZE=4194304 1>/dev/null
% du -sh build/zephyr/zephyr.elf
456K    build/zephyr/zephyr.elf

% west build -p -b qemu_riscv64 samples/hello_world 1>/dev/null
% du -sh build/zephyr/zephyr.elf
440K    build/zephyr/zephyr.elf

@foxriver1025 Could you file an issue here on GitHub, and provide instructions to recreate the behavior you described here?

[foxriver1025]

@fkokosinski It's zephyr.bin that gets bigger, not zephyr.elf, like this:

$west build -p -b qemu_riscv64 zephyr/samples/hello_world -- -DCONFIG_BUILD_OUTPUT_BIN=y
$du -sh build/zephyr/zephyr.bin build/zephyr/zephyr.elf
36K     build/zephyr/zephyr.bin
416K    build/zephyr/zephyr.elf

$west build -p -b qemu_riscv64 zephyr/samples/hello_world -- -DCONFIG_BUILD_OUTPUT_BIN=y -DCONFIG_HEAP_MEM_POOL_SIZE=4194304
$du -sh build/zephyr/zephyr.bin build/zephyr/zephyr.elf
4.1M    build/zephyr/zephyr.bin
432K    build/zephyr/zephyr.elf

zephyr.bin increased to 4M in size

[fkokosinski]

It's zephyr.bin that gets bigger, not zephyr.elf

ACK. We could indeed try to optimize the size by moving the heap to be the last section. I still don't see how this is a RISC-V specific issue, though, so this is more of a feature request than a bug report IMO, because the same behavior can be observed for archs as well:

% west build -p -b qemu_cortex_a9 samples/hello_world -- -DCONFIG_HEAP_MEM_POOL_SIZE=4194304 -DCONFIG_BUILD_OUTPUT_BIN=y 1>/dev/null
% du -sh build/zephyr/zephyr.bin
4,9M    build/zephyr/zephyr.bin

% west build -p -b qemu_x86 samples/hello_world -- -DCONFIG_HEAP_MEM_POOL_SIZE=4194304 -DCONFIG_BUILD_OUTPUT_BIN=y 1>/dev/null
% du -sh build/zephyr/zephyr.bin
4,2M    build/zephyr/zephyr.bin

[foxriver1025]

@fkokosinski I can understand what you mean. It's not a behavior unique to risc-v, but I think this may be a problem because flash space is precious on embedded devices and there is no static data in system memory. Therefore, it's not possible to increase the size of the bin just because system memory is used, which will prevent the bin file from being programmed to flash.