From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26282 invoked by alias); 7 Jun 2012 07:31:12 -0000 Received: (qmail 26273 invoked by uid 22791); 7 Jun 2012 07:31:11 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.securitas-direct.com (HELO mail.securitas-direct.com) (91.199.64.45) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jun 2012 07:30:57 +0000 Received: from unknown (HELO sdwands2.sec.intra) ([172.30.40.21]) by mail.securitas-direct.com with ESMTP; 07 Jun 2012 09:30:55 +0200 MIME-Version: 1.0 In-Reply-To: <87pq9cgv6j.fsf@fleche.redhat.com> References: <87pq9cgv6j.fsf@fleche.redhat.com>, Subject: Re: Simple suggestion to get basic core-file alike functionality for bare-metal targets From: Fredrik Hederstierna To: Tom Tromey Cc: gdb@sourceware.org Message-ID: Date: Thu, 07 Jun 2012 07:31:00 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00038.txt.bz2 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. ar= m-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 toolcha= in 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 patchi= ng gdb sources and to get community support. Note, we don't have a real OS, we are bare-metal, using just a simple sched= uler. 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 wrote: ----- To: Fredrik Hederstierna From: Tom Tromey Date: 06/06/2012 08:19PM Cc: gdb@sourceware.org Subject: Re: Simple suggestion to get basic core-file alike functionality f= or bare-metal targets >>>>> "Fredrik" =3D=3D Fredrik Hederstierna 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. =A0The 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