Further work to support C++ Exceptions

[devyte]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: All
• Core Version: >= 5.2.0-beta3
• Development Env: All
• Operating System: All

Settings in IDE

• Module: All
  -Exceptions: Enabled

Problem Description

C++ Exceptions are now implemented. However, they are disabled by default. Enabling Exceptions increases bin size by a huge amount, up to 200KB depending on the application and libs linked in. This issue is meant to track further work to mitigate that.

• Investigate the reason for the big bin size increase
• Add noexcept to functions that can't throw
• figure out other ways to reduce bin size, if at all possible

Related to #1351

[earlephilhower]

Big bin increase is due to the eh_tables, a standard DWARF2 exception handler format. I doubt that they can be shrunk without massive rework.

However, maybe they can be moved out of progmem space and stored in a separate part of flash, enabling the full 1MB of code to be used.

It might be possible to build a pseudo-VM system (only on the data side, not insn) by having the linker align the eh_tables to an invalid address range. We would then install an exception handler which would take the invalid address, use that as an offset into raw SPI flash, and do a SPI read of the requested 32bits (or, more smartly, a 256byte or so cache) from the eh_tables location outside the PROGMEM space in flash, and return to the exception handler.

[devyte]

This is a VERY interesting idea. Would it mean a second bin with the eh tables, to be flashed separately?

[earlephilhower]

Yeah, another section would be defined by us (like FS_START/_END) and it would need to be updated with the main code. Doesn't help people who are out of space for OTA (i.e. you'd still want to upload the BIN and EHTABLES in one swoop, since if the eh tables are out of sync the app won't handle throws properly), but does let you get 1MB of code.

This was just an idea. I assume that undefined memory regions result in HW exceptions, but that's probably dependent on how they configured the RTL for the core. If that's not there, this obviously is a non-starter.

[devyte]

Note: the other option is #6681: figure out how to build a bin > 1MB.