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

Fredrik Hederstierna fredrik.hederstierna@securitas-direct.com
Thu Jun 7 07:31:00 GMT 2012


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



More information about the Gdb mailing list