Re: Simple suggestion to get basic core-file alike functionality for bare-metal targets

[Fredrik Hederstierna <fredrik dot hederstierna at securitas-direct dot com>]

Hi Tom,
Thanks for your answer.

Actually I tried to suggest something like this in a previous post

http://sourceware.org/ml/gdb/2012-04/msg00073.html

but I got no replies at all unfortunately.

I agree and think the best would be to define a core-file format for eg. arm-none-elf/eabi in my case.
But since the path there seemed very far, I assumed there possibly were a 'nearer' path to get some 'core' core-file support.
This would include storage of basic CPU state, like registers and memory to a secondary storage format (file).

If any GDB maintainer, or anyone that have deep knowledge of the core-file framework, could 'point in any direction' to start work with this, I would be glad to help.
And what are the probability that arm-none-targets would find a common core-file format that could be accepted by the community?
Today we are 'mocking' additional linux-core support in our arm-elf toolchain build,
and let gdb 'pretend' our core-files are arm-linux, to be able to read our arm-none core-files.
This actually works fine, but are not very clean nor beautiful code.
It would be nice to have a 'real' arm-none-core-file format to avoid patching gdb sources and to get community support.

Note, we don't have a real OS, we are bare-metal, using just a simple scheduler.
This is a common case I think for small embedded systems using the ARM bare-metal target toolchain.

Thanks again for your reply, and Best Regards!
/Fredrik

-----Tom Tromey <tromey@redhat.com> wrote: -----
To: Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com>
From: Tom Tromey <tromey@redhat.com>
Date: 06/06/2012 08:19PM
Cc: gdb@sourceware.org
Subject: Re: Simple suggestion to get basic core-file alike functionality for bare-metal targets

>>>>> "Fredrik" == Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> writes:

Fredrik> Note though, that the dump files needs to be generated by
Fredrik> debugged code itself, if running without connection to
Fredrik> GDB. This to examine eg. crashes off-line later. ?The point is
Fredrik> to get some kind of standard format and to ease the restoring
Fredrik> of registers etc.

Fredrik> I can consider to look into adding the dump-register command
Fredrik> and put some own time into this, if the community think its a
Fredrik> good idea?

I didn't see a reply to this.

If you're going to go this far, and also add support for this to some
OS, why not just implement "real" core files?

Tom