From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26427 invoked by alias); 11 Apr 2012 14:29:15 -0000 Received: (qmail 26417 invoked by uid 22791); 11 Apr 2012 14:29:14 -0000 X-SWARE-Spam-Status: No, hits=-1.2 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; Wed, 11 Apr 2012 14:29:01 +0000 Received: from unknown (HELO sdwands2.sec.intra) ([172.30.40.21]) by mail.securitas-direct.com with ESMTP; 11 Apr 2012 16:28:59 +0200 MIME-Version: 1.0 In-Reply-To: References: Subject: Core file support for bare metal ARM eabi/elf-none-targets? From: Fredrik Hederstierna To: gdb@sourceware.org Message-ID: Date: Wed, 11 Apr 2012 14:29: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-04/txt/msg00073.txt.bz2 Hi I use bare-metal GCC/GDB arm-none-elf and arm-non-eabi toolchains. It would be great if also 'non-Linux' targets could benefit from core-file = support. Systems using just a simple scheduler, or a simple embedded OS, could possi= bly generate core-files 'by hand' when crashing or asserting. Our system eg. does put all RAM in a dedicated flash sector when asserting,= then after reboot system, a core-file is generated and retrieved by a deve= loper at a later time. I guess this is a common and simple way of generating a core-file in an emb= edded system. Also the core-files can be sent in from the field from real customers, and = not only while being connected with GDB and JTAG. The problem is that the 'bare-metal' GDB seems not to support core-files, I= guess to arm-none format is undefined. So currently we 'fake' the core-file to be an Linux-core, but this does not= seem right (even though it works fine). If I look in "arm-tdep.c" in function "arm_gdbarch_init()", there is no sup= port for core-file in the setup. The 'configure.tgt' does not even include 'corelow.o' for none-target: arm*-*-*) =A0=A0=A0 # Target: ARM embedded system =A0=A0=A0 gdb_target_obs=3D"arm-tdep.o" =A0=A0=A0 gdb_sim=3D../sim/arm/libsim.a =A0=A0=A0 ;; In "arm-linux-tdep.c" there is support for Linux-core in the setup, making = calls like: /* Core file support. */ set_gdbarch_regset_from_core_section (gdbarch, arm_linux_regset_from_core_section); set_gdbarch_core_read_description (gdbarch, arm_linux_core_read_descripti= on); if (tdep->have_vfp_registers) set_gdbarch_core_regset_sections (gdbarch, arm_linux_vfp_regset_section= s); else if (tdep->have_fpa_registers) set_gdbarch_core_regset_sections (gdbarch, arm_linux_fpa_regset_section= s); set_gdbarch_get_siginfo_type (gdbarch, linux_get_siginfo_type); What if some of this could be moved up to 'arm-tdep.c', or could it possibl= y be defined a basic core-file for a 'arm-none-target'? This core format could possibly be used by all bare metal ARM systems for b= asic debugging? Thanks & Best Regards, Fredrik Hederstierna