[Feature request] Support alternative symbol resolving implementations for elf_loader (AEGHB-1241)

[KenVanHoeylandt]

Currently symbol loading works with 3 pre-defined lists:

• A subset of libc
• A subset of esp-idf
• A custom set of user symbols

I encountered some problems with this in my project:

• The libc and esp-idf subsets are limited, so I have to define my own.
• I can't use the elf_loader as a library component: The symbols are present in my main firmware, so the library fails to compile as it cannot find the symbols. (my solution was to fork the project and make the necessary adaptations)

My suggestion is to change the way uintptr_t elf_find_sym(const char *sym_name) works. If we use a function pointer as proxy, we can override the loading behaviour where desirable:

The implementation could look like this:

elf_symbol.h

uintptr_t elf_find_sym(const char *sym_name);

typedef uintptr_t (*symbol_resolver)(const char *sym_name);
/** Override the behaviour of `elf_find_sym()` */
void elf_set_symbol_resolver(symbol_resolver resolver);

elf_symbol.c

static symbol_resolver current_symbol_resolver = &elf_find_sym_default;

uintptr_t elf_find_sym_default(const char *sym_name)
{
    // Default implementation goes here instead of at elf_find_sym()
    // See https://github.com/espressif/esp-iot-solution/blob/6747dca0ec2dcb4a1a0bec17fef6d7ea3693b858/components/elf_loader/src/esp_elf_symbol.c#L159
}

uintptr_t elf_find_sym(const char *sym_name)
{
    return current_symbol_resolver(sym_name);
}

This would cover quite a few use cases:

• The default behaviour as above (statically defined lists)
• Override the default behaviour with custom libc/esp-idf bindings
• Add as many lists of symbols as you like
• Resolve larger lists of function mappings quicker with hash map implementation.
• Selectively load sets of lists depending on the app that is loaded: For example one app might want LVGL bindings but another does not. Allowing this granularity will speed up the time it takes to resolve all functions for that app, and it can even be used for rudimentary security measures (e.g. an app that doesn't get access to esp_http_client APIs)
  ... and all of these features would be possible to implement without having to support it directly from the library!

I'm going to implement this in my fork of elf_loader, but I wonder whether this feature would be allowed to be back-ported into the official library. I'm also interested in feedback on the proposal.

Updated: PR with draft proposal: #588