As Klaus Rudolph wrote:
It's a fairly homegrown (of the old simulavr) text file. I'm
attaching one for reference. Also, it's always using a fixed name.
objdump will do the job as well.
But again, since the simulator has the name "simulavr" (just as the
old one), any script using it might expect it behaving the same as the
older one used to. At the very least, that's what will cause the
smallest effort for anyone who's been using it inside scripts.
For everything else, the first step has to be to detect which
simulator actually being faced with, and then act upon. objdump
itself is only part of the game, since its output would only generate
something that is similar to the older coredump format, but still
sufficiently different so you have to postprocess it anyway.
Because avr devices have a very small memory footprint it is no problem
to duplicate the programm/symbols content to the core file.
The old "core" file format did duplicate the flash ROM part but it
doesn't know about symbols (because old simulavr could not read ELF
directly anyway, only raw binary).
Thanks for adding it. The format is a standard C string so you could
use strtoul(..., 0).
Actually we use strtol(,16).
...which is the reason for the ambiguity you see ("f1" being detected
as a number rather than a symbol).
I don't know if it's already too late to change, but I'd vote for
requiring the user to specify numbers in C notation, i.e. a
hexadecimal number has to be prefixed with 0x. That way, it can
always be distinguished from a symbol as symbols could not start
with a digit 0.