Increase free IRAM

[earlephilhower]

Move system fault handler to flash, use new printf

• The __wrap_system_restart call has been in flash for quite a while and
  seems to be working fine. There were some support routines that were
  placed in IRAM (mistakenly thinking the wrap_restart caller was also in
  IRAM) which are now moved to flash.
• Clean up the printf code to use the new stdlib which handles PGM_P
  strings as format and arguments without any difficulty.

Move functions out of IRAM when possible

• umm_init() is called in OS startup after flash is enabled, and never again.
• cont_get_free_stack() shouldn't be called from IRQ.

Make STR macro more unique

• Add double-underscores to some string assistance macros to avoid
  conflicts with user applications.

[earlephilhower]

As a simple test, the ESPEasy sketch from #5476 shows:

• BIN size = 274 bytes saved
• HEAP = 0 change
• IRAM = 672 bytes saved

Before merge I need to manually run a fault test for each of the many, many ways the core can crash, just to verify none of the string replacements got broken.

[earlephilhower]

Latest push reduces, in total:
BIN: 2638 bytes(!)
IRAM: 672
HEAP: 0

[earlephilhower]

Tested an uncaught throw, a false assert, a null-reference, a processor exception in an interrupt, and a ROM exception, and they all dumped and decoded fine (when using #5502 toolchain GDB to avoid the dynlink problem).

#include <assert.h>
#include <core_esp8266_waveform.h>

static uint32_t ICACHE_RAM_ATTR boom()
{
  static int cnt=0;
  if (++cnt==100) *(int*)0=1;
  return 10000;
}

void setup() {
  // put your setup code here, to run once:
Serial.begin(115200);
Serial.printf("hello\n");
//throw(std::runtime_error("oops"));
//assert(1==2);
//*(int*)0=1;
//setTimer1Callback(boom);
os_printf(NULL);
}

void loop() {
}

[devyte]

Does it make sense to turn those tests into formal device tests?

[earlephilhower]

It may be possible with lots of effort, but doesn't fit into the existing framework at all.

Since your main app code no longer runs when the expected behavior happens, the pass/fail prints can never happen. So can't use the test harness. Some complicated expect jiggery might be doable, but these will not be exact matches (i.e. stack pointer will change slightly, PC address, etc. depending on build).