public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Simple suggestion to get basic core-file alike functionality for bare-metal targets
Date: Thu, 07 Jun 2012 07:31:00 -0000	[thread overview]
Message-ID: <OF7B1D0ACF.1CE3D660-ONC1257A16.00294884-C1257A16.0029488A@securitasdirect.se> (raw)
In-Reply-To: <87pq9cgv6j.fsf@fleche.redhat.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

      parent reply	other threads:[~2012-06-07  7:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04  9:33 Fredrik Hederstierna
2012-06-06 18:19 ` Tom Tromey
2012-06-07  7:31 ` Fredrik Hederstierna [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF7B1D0ACF.1CE3D660-ONC1257A16.00294884-C1257A16.0029488A@securitasdirect.se \
    --to=fredrik.hederstierna@securitas-direct.com \
    --cc=gdb@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).