elf2image: Use map file instead of xtensa-lx106-elf-nm

[nekromant]

The current elf2image implementation uses xtensa-lx106-elf-nm. However if we compile the binary with -ffunction-sections/-fdata-sections and do -gc-sections to strip unused functions from the resulting binary we'll end up with this error message:

  [ESPTOOL]   images/antares.rom
xtensa-lx106-elf-nm: images/antares.elf: no symbols
Traceback (most recent call last):
  File "/home/necromant/bin/esptool.py", line 471, in <module>
    image.entrypoint = e.get_symbol_addr("call_user_start")
  File "/home/necromant/bin/esptool.py", line 283, in get_symbol_addr
    return self.symbols[sym]
KeyError: 'call_user_start'
make: *** [images/antares.rom] Error 1

Proposed solution: Link with -Wl,-Map=$(IMAGENAME).map
and pass either the whole mapfile or the just the call_user_start address to esptool.

[nekromant]

@pfalcon If I'm not mistaken, you are the one who implemented the magic required to generate rom images?

[pfalcon]

Well, if you look at that code, call_user_start is a special, magic function, the real start address (aka entry point) to which the vendor bootloader jumps to start the app. So, it's not recommended to get rid of the standard implementation of that function (you may need to pull it in explicitly using appropriate linker switch). And if you did get rid of it, and are sure you're right with that, that I suggest to just call you own entrypoint (or its wrap) such to avoid confusion. (I myself would love to get rid of all that vendor mess and have just normal "main", but as you know, there's rather long way to that, so if we can't do it right, let's stick to vendor's stuff, and not invent something 3rd yet).

[nekromant]

@pfalcon I know that and I did NOT get rid of call_user_start, it's there. The problem is that after stripping the elf file is missing symbol information. e.g. call_user_start is there, but you can't find it by symbol name.
As of an even better option I've just noticed - it looks like ELF entry point IS the address of call_user_start, so using elf entry point would be an even cleaner approach, rather than generating a map file and reading an address from it.
-gc-sections comes very handy in terms of reducing code size.

[pfalcon]

Ah, I see. I'd still wonder why --gc-sections removes symbols information - symbols are not in a section, it is separate structure in ELF file, right? But if you say it does, then well, something needs to be done for sure.

I'd suggest starting with ability to override entry point address - "make_image" already takes --entrypoint, there it's required param, "elf2image" can take it optional, as override. Then look if it's possible to have sed one-liner to extract it from a map file, if not, add optional ability to parse map file to esptool indeed. My 2 cents ;-).

[nekromant]

If what I remember about ELF format, symbols are stored in .symtab/.dynsym sections. Since they are not referenced by any code in the actual firmware (why should they?) they get ditched by -gc-sections, which looks kind of sane and expected.
Using ELF entry point instead of embedding sed onliners into python code looks like the best solution so far. I think I'll throw up a patch as soon as I get a spare minute.

[pfalcon]

See #24 which touches this somehow.

[projectgus]

I think this is fixed since a0c18ea, now that the entry point is read from the ELF. I'm able to compile esp-open-rtos images with -ffunction-sections/-gc-sections, and also different entry point names, and it all seems happy.

So I'm closing this for now, please reopen if you think there's still an issue here.