Interactive call to arbitrary C-function

[wolfgangr]

What I want:
When I implement a new functionality or a new piece of hardware, i'd like to try out calling C-functions already compiled into the sketch that might be useful for that job without the usual C-recompile-reflash cycle.
After playing, testing, figuring things out, it would be nice if this feature then could be impleemted in persistent code.
Thus the development time might go down dramatically, which is important for projects with small lot sice (which may be close to one)

How it seems possible:
This issue is a companion / subset to #15 .
cforth contains an interface to call arbitrary C functions.
This is used heavily in the implementation, but presumably also accessible on the user command line. I might also be possible to use it in event handler snippets, e.g for interrupt or command handlers.
Forth side calling interface:
https://github.com/MitchBradley/cforth/blob/esp32-v1.0/src/cforth/ccalls.fth
C-side implementation:
https://github.com/MitchBradley/cforth/blob/esp32-v1.0/src/cforth/forth.c
(search for ccall in this lengthy file)

The address required to call a C-function can be extracted from the symbol table.
xtensa-lx106-elf-objdump -t somebinary.o | less
We might want to figure out where on our build tree the last binary that reveals its structure to objdump is available. Preferrably this wold be the binary to flash, but this may require some massage, since it is linked to the esp blobs, which might confuse objdump. There may also be address changes between the flash.bin and the address visible in the running module due to the ESP8266 memory organisation model (flash address mapping).

However, jumping into adresses extracted from a specific build is risky and should be limited to the experimental stage.
On a recompile, the addresses are subject to change and the call will fail. Nasty things may happen.
Therefore it were preferrable to extract the address of a C-function to be called from inside the currently running flash. This would require a reimplementation of some functionality of objdump in C or (preferrably) in forth. To that end, we need the location of the symbol table (preferrable in flash address) and the format definition of its data structure.

Preliminary collection of pointers for further research:
https://docs.freebsd.org/info/stabs/stabs.info.Symbol_Table_Format.html
https://sourceware.org/binutils/docs/binutils/objdump.html
https://www.tutorialspoint.com/compiler_design/compiler_design_symbol_table.htm
https://github.com/jcmvbkbc/binutils-gdb-xtensa/blob/master/binutils/objdump.c

Any assistance in figuring the secrets of the symbol table is appreciated.

[wolfgangr]

just grepped through some binaries and hexdumps.
Maybe that the symbol table aka debug information get's stripped by the flashing tool, or by the linker when preparing the flash (maybe depending on linker settings?)
Of course this informations costs flash space.
So if this is low in supply, we may face a tradeoff.