A guinea-pig binary for bloat checks

[ivmarkov]

As per the documents inside the binary code, it is specially crafted so that all memory except the stack is reported towards the .bss section.

For this to happen, all rs-matter types are allocated statically.
This includes the futures (whose size is anything but trivial), which are moved/emplaced into .bss by the specific executor which is utilized (embassy-executor).

TBDs:

• Check why the code size reported for the riscv32imac target is more than twice as big as the thumb targets. Might just be due to the compressed size of the thumb instructions (16bit) or there could be something else going on for riscv32, as in linking to binaries we don't need and use, but not removed by the LTO
• Fix the large "responder" future by splitting it into multiple tasks in an embassy-executor task pool. This should reduce these 20KB down to ~ 10KB on x64 and even less for the other targets

[ivmarkov]

@kpschoedel Would appreciate your expertise here. :)

Since this PR, the repo somehow stopped sending size reports.

What I changed which might affect it (all questionable changes are in size-check.yml):

• The cfg key is renamed from linux.cfg to cross-platform.cfg (because rustc is a cross-compiler and we compile for multiple different targets at once). The GH workflow reports a warning:

WARNING:root:Missing config file: scripts/tools/memory/platform/rs-matter-core.cfg

... but it did report the same warning when the configuration was previously named linux.cfg ?!

• The values in the "platform" "target" and "config" are now different. My understanding from @gmarcosb is that they could be anything, and I therefore changed those to report meaningful stuff to us:
  • "Platform" (?!) now contains a descriptive name of the binary which is size-checked
  • "Target" now contains the full Rust target, which is super-useful
  • "Config" now contains a string which tries to provide a short description of how the binary was compiled (i.e. compiler optimization settings and others)

I wonder:

• Do I have to follow some sort of specific values for the three columns from above?
• Should the cross-platform.cfg exist?
• Should the value in the "Platform" match the name of the "cfg" file,?

[ivmarkov]

@kpschoedel Would appreciate your expertise here. :)

Since this PR, the repo somehow stopped sending size reports.

What I changed which might affect it (all questionable changes are in size-check.yml):

• The cfg key is renamed from linux.cfg to cross-platform.cfg (because rustc is a cross-compiler and we compile for multiple different targets at once). The GH workflow reports a warning:

WARNING:root:Missing config file: scripts/tools/memory/platform/rs-matter-core.cfg

... but it did report the same warning when the configuration was previously named linux.cfg ?!

• The values in the "platform" "target" and "config" are now different. My understanding from @gmarcosb is that they could be anything, and I therefore changed those to report meaningful stuff to us:

  • "Platform" (?!) now contains a descriptive name of the binary which is size-checked
  • "Target" now contains the full Rust target, which is super-useful
  • "Config" now contains a string which tries to provide a short description of how the binary was compiled (i.e. compiler optimization settings and others)

I wonder:

• Do I have to follow some sort of specific values for the three columns from above?
• Should the cross-platform.cfg exist?
• Should the value in the "Platform" match the name of the "cfg" file,?

@kpschoedel Scrach that ^^^. While typing this comment, it finally reported the new values. :)

[kpschoedel]

Yes, the names are arbitrary. ‘Platform’ is associated with a configuration file and (in the C++ tree) corresponds to a hardware/toolchain combo, close to ‘target’ in the toolchain sense, whereas ‘target’ reads as ‘build target’ (and ‘config’ matches your usage). The platform configuration is optional and probably not necessary for you since you don't have a multiplicity of vendor section/symbol conventions.