exception playground

[d-a-v]

Out of curiosity, I tried to enable exceptions.
With these changes and a random sketch, flash size is increased by 40KB, and a hundred bytes in ram.
It compiles and run until a throw test supposed to be catch(...)ed, which ends up in an abort() call (nothing is executed after the throw).
I'm not sure whether I'm playing with fire but I'd like to understand the (un)feasibility of the thing.

[devyte]

CI failed due to linker complaining

[devyte]

Ok, so let me get this straight:

• This adds ~40KB of bin size
• This adds maybe 100 bytes of mem usage
• Exceptions can be thrown but not caught

I know less than nothing about the voodoo involved here, but it sounds to me like this is pretty close to viable.

• We can deal with the increased bin size. The 40KB could be investigated to figure out what is in there. We could even make exceptions a build option, if reduced bin size is needed by several users. The point is that there are several paths forward to pursue about increased bin size, so this does not worry me one bit.
• 100 bytes of mem usage is a price more than worth paying to get real exceptions. I do understand that this was after moving .rodata to flash. That may have implications, e.g.: ISRs could not throw.
• Not being able to catch is a problem. Is the CI linker error related?

Overall, I think that if catch gets fixed, then maybe we're good for a first version.

@igrr @earlephilhower what are your thoughts on this?

[d-a-v]

This is needed somewhere (for Travis-CI too):

void __gnu_cxx::__verbose_terminate_handler ()
{
  //os_printf("exception\r\n");
  //i_was_here = 42;
  //panic();
}

[igrr]

There are a few more things missing for exception support...

1. libstdc++ needs to be built without -fno-exceptions flag (this seems to be the case already)
2. need to call __register_frame_info, before executing constructors for global objects
3. above call will result in libstdc++ allocating 16kB from heap for emergency exception pool. This probably makes sense on desktop but not much sense on a small embedded platform that esp8266 is. We probably need to reduce this size and/or make it adjustable, like this is done in this patch. Then a weak function can be overridden to adjust emergency pool size from the application.
4. a few more changes to the linker script to catch sections produced with -ffunction-sections -fdata-sections
5. either override __verbose_terminate_handler or, better, build gcc with --disable-libstdcxx-verbose to disable verbose terminate handler
6. make the exception support configurable (yet another menu option, boards.txt.local flag) or just bite the bullet and enable it for everyone.

[devyte]

For me this is an area that has a sign that says "here be dragons", but it sounds like it would be more or less straightforward for someone with the right knowledge.
@earlephilhower any chance you could take this further?

[d-a-v]

In addition to exceptions above, and if we come to try with gcc changes, let's not forget #4520:

• gcc patches for removing full path in __FILE__
• LTO support
• #define JUMP_TABLES_IN_TEXT 1 to save more heap

@igrr one can always start from scratch (with jcmvbkbc/gcc-xtensa or? pfalcon/esp-open-sdk).
It is not clear to me if you have a particular recipe for esp8266/Arduino.
In the positive case, would it be wise to put this recipe somewhere in this (or another) repo, as a script, link, submodule, also with your newlib-xtensa, and with a set of patches to try / optionally use / include under a subdirectory ?

[d-a-v]

@earlephilhower You also have the beginning of an answer.

What I'm pushing for is a common place to start experiments with. That way interesting findings, even if not rightly used, can be stored and visible for a later review when someone have time to play with.

[devyte]

Closing in favor of #5376 .