From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17481 invoked by alias); 6 Jul 2007 11:26:42 -0000 Received: (qmail 17473 invoked by uid 22791); 6 Jul 2007 11:26:41 -0000 X-Spam-Check-By: sourceware.org Received: from mms3.broadcom.com (HELO MMS3.broadcom.com) (216.31.210.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jul 2007 11:26:34 +0000 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 06 Jul 2007 04:26:22 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 562882AF; Fri, 6 Jul 2007 04:26:22 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 429382AE for ; Fri, 6 Jul 2007 04:26:22 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FLG67703; Fri, 6 Jul 2007 04:26:21 -0700 (PDT) Received: from NT-IRVA-0752.brcm.ad.broadcom.com ( nt-irva-0752.brcm.ad.broadcom.com [10.8.194.67]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id A1B2D69CA3 for ; Fri, 6 Jul 2007 04:26:21 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Loading a Core File Date: Fri, 06 Jul 2007 11:26:00 -0000 Message-ID: From: "Robert Norton" To: gdb@sourceware.org X-WSS-ID: 6A90F9543AC20148625-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2007-07/txt/msg00048.txt.bz2 Hi, =20 Our built in simulator (using remote-sim.c) has the ability to load core files via a custom command 'sim loadcore'. This causes the simulator to load all the state from the core file, but it doesn't but GDB into a state which is suitable for examining core files. We can do this with some trickery to fool gdb into thinking it is in a running state e.g.: =20 target sim load break main run sim loadcore =20 But this is arcane and doesn't result in a completely consistent state e.g. some things are still cached by gdb which isn't aware that memory / registers have just changed under its feet. I borrowed the following from corelow.c: target_fetch_registers (-1); =20 /* Now, set up the frame cache, and print the top of stack. */ flush_cached_frames (); select_frame (get_current_frame ()); =20 But it's not a complete solution. What is the 'proper' way of doing core files in gdb? What is involved in getting it to work via 'target core'? =20 Many thanks, =20 Robert