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

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

[Fredrik Hederstierna]

When debugging with bare-metal targets often core-file alike support would be nice.
Though many targets lack core-file support.

If GDB is connected you could eg. store RAM using

  dump memory filename.bin start_addr end_addr
  restore filename.bin binary start_addr

then save registers by hand to save 'basic' core-file data.

Wouldn't it be great to

1. Have similar command to dump also all registers / CPU-states to file?
   Eg. dump registers filename.reg
   Then be able to restore them
   restore filename.reg registers

2. Perhaps have a generic 'core-light-file' format.
   This could contain memory + registers (+ maybe more basic CPU states)?

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

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

Thanks and Best Regards
Fredrik

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

[Tom Tromey]

>>>>> "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

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

[Fredrik Hederstierna]

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