Enable -Wstack-usage on device builds

[kpschoedel]

Problem

RAM on small devices is limited, so excesssive stack should not be used
without good reason. Stack allocation is also not easily checked at run
time so overflow is likely to cause crashes.

Summary of Changes

• Add a -Wstack-usage compiler flag on embedded builds. (For this
  purpose, an ‘embedded build’ is any that is not using a whitelisted
  non-embedded OS, so new platforms will have this enabled by default.)

  In this PR, the stack limit is set high enough that only dynamically
  unbounded stack usage triggers it. The intent is to lower the limit
  in the future so that any unusually large stack requires whitelisting
  with justification in review.

• Replace most uses of dynamically unbounded stack.

• Filed separate issues for two remaining uses of dynamic stack:

  • Unbounded stack in emberAfPrintBuffer() #3662 emberAfPrintBuffer()
  • Unbounded stack in src/setup_payload #3663 payloadBase41RepresentationWithTLV()

fixes #3505 Use "-Wstack-usage" for device builds

[gerickson]

Thanks for doing this!

[github-actions]

Size increase report for "esp32-example-build" from 99aaed7

File	Section	File	VM
chip-wifi-echo.elf	.flash.rodata	336	336
chip-wifi-echo.elf	.flash.text	-208	-208

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize
.flash.rodata,336,336
.debug_str,0,96
.xt.prop._ZN4chip8Encoding12LittleEndian7Write32ERPhj,0,1
.debug_aranges,0,-8
.debug_frame,0,-28
.xt.prop._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendERKS4_,0,-76
.xt.prop._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEpLERKS4_,0,-76
.strtab,0,-78
.xt.prop._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKcj,0,-100
.xt.lit._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag,0,-120
.symtab,0,-144
.debug_ranges,0,-168
.flash.text,-208,-208
.debug_abbrev,0,-268
[Unmapped],0,-336
.shstrtab,0,-446
.debug_line,0,-641
.debug_loc,0,-760
.debug_info,0,-3904

[vivien-apple]

It makes me a bit sad to have to fix ManualSetupPayloadGenerator.cpp and QRCodeSetupPayloadGenerator.cpp for stack usage. That would make the code a bit less readable and harder to maintain.

For the rest of CHIP that definitively makes sense.
For those files I think the initial intent was that the code that creates the manual/QR code was not designed to be shipped on devices. We mostly have used that as an easy way to create a QRCode on the M5Stack while developing. I wonder if instead of fixing those files, it is time to just get those files out of the devices (not in this PR though).

Thoughts ?

[kpschoedel]

I have no objection to leaving it. The main goal of this PR is to make sure it doesn't happen by accident or get overlooked in new code.

[kpschoedel]

So, for this PR I've replaced the ManualSetupPayloadGenerator.cpp with a #pragma and TODO #3663. Then a follow-up PR can remove the TODO and close #3663, so that it's recorded that this stack usage is OK.