Added GH Action to show FLASH diff using bloaty

[alexcekay]

Solved Problem

Increase awareness of the impact of a code change on FLASH size. Allow developers to see exactly how much and where their change will increase FLASH usage.

Solution

• In case of a PR:
  • Compile the base revision
  • Compile the current revision of the branch
  • Diff the flash usage using bloaty
• In case of a commit on main:
  • Compile the previous main revision
  • Compile the current main revision
  • Diff the flash usage using bloaty

Alternatives / Future

This is an initial working version that includes the following two boards:

• px4_fmu-v5x
• px4_fmu-v6x

If we want, we can easily add more boards in the future.

This version compiles 2 times for each board (1 compile before / 1 compile after) to create the diff. With two boards this results in 4 compiles, which is fast and only creates a small overhead. If we add many more boards, we should reuse the artifacts created by other jobs. However, this will increase the complexity of the code as an external script will need collect the artifacts from the base and current revisions and unpack them.

In addition bloaty has the tendency to detect non-existing remappings (like in the comment below) when there are no changes. In case of real changes the output is however really useful as can be for example seen here:

alexcekay#2

[github-actions]

FLASH Analysis

px4_fmu-v5x

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%      +8  +0.0%      +8    .text
  -0.0%      -8  [ = ]       0    [Unmapped]
  [ = ]       0  +0.0%      +8    TOTAL

px4_fmu-v6x

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%      +8  +0.0%      +8    .text
  -0.0%      -8  [ = ]       0    [Unmapped]
  [ = ]       0  +0.0%      +8    TOTAL

[PetervdPerk-NXP]

Do you have an example of the bloaty build causing a segfault. It did not happen yet on any of the tests of the action on my fork. With an example of the segfault I can diff which version is used there and in my action.

I don't have a particular example at the moment, but it was related to this bug which was fixed later.
google/bloaty#208
Hence the recommendation to update bloaty so it won't crash.

Regarding RAM: The static RAM part is included in bloaty via .bss and .data. This is however only a rather small part in PX4 due to most of the RAM usage being caused by mallocs. We plan to add a dynamic execution for measuring RAM (heap) usage

I agree that most RAM usage is in malloc(), but if someone prealloc data on the heap where they shouldn't it should be notified.
For example #18380

[alexcekay]

Hence the recommendation to update bloaty so it won't crash.

Yes, that sounds reasonable. Bloaty does not seem to make any official releases anymore. So I will create a fork of https://github.com/carlosperate/bloaty-action next week and bump the used bloaty version to one of the recent commits in the bloaty repo.

I agree that most RAM usage is in malloc(), but if someone prealloc data on the heap where they shouldn't it should be notified.

This will be caught by bloaty. As an example, I have compiled the following https://gist.github.com/alexcekay/756864c1f8ace3db3b4fe34c8bf49da7 once with and once without st_h being present. This will be noted in the bloaty diff output:

  +1.2%     +16  +1.2%     +16    .data                                                              
    [NEW]     +12  [NEW]     +12    ram.c
    +0.3%      +4  +0.3%      +4    [section .data]

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-nov-6-2024/42264/1

[niklaut]

Yes, please!

[dagar]

I also find the symbols size change helpful for comparison.

FYI we have some helpers for bloaty in tree. https://github.com/PX4/PX4-Autopilot/blob/main/cmake/bloaty.cmake