From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21484 invoked by alias); 30 Apr 2009 19:31:31 -0000 Received: (qmail 21474 invoked by uid 22791); 30 Apr 2009 19:31:29 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Apr 2009 19:31:24 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5376A2B00C; Thu, 30 Apr 2009 12:31:23 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost2.vmware.com (Postfix) with ESMTP id 40B638ECC0; Thu, 30 Apr 2009 12:31:20 -0700 (PDT) Message-ID: <49F9FABF.6040108@vmware.com> Date: Thu, 30 Apr 2009 19:40:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: David Daney , "gdb@sourceware.org" Subject: Re: Remote core file debugging References: <83k552dkw3.fsf@gnu.org> <49F9F712.8060801@caviumnetworks.com> <83hc06djug.fsf@gnu.org> In-Reply-To: <83hc06djug.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2009-04/txt/msg00241.txt.bz2 Eli Zaretskii wrote: >> Date: Thu, 30 Apr 2009 12:08:02 -0700 >> From: David Daney >> CC: gdb@sourceware.org >> >> I must be missing something, but why can't you move the core file to the >> debugging host and debug it there with gdb? > > Sorry, I should have said that in the first place: because it's huge, > and there are quite a few of them. It's not a single target system, > either: there are a few dozen of them, so copying huge core files from > all of them would be at least time consuming if not impractical. GDBserver cannot currently do what you want. Options include 1) Teach gdbserver to understand core files, and 2) Write a corefile server that understands gdb serial protocol. #2 might be a bit easier, at least if you start with libbfd which already knows how to read core files. Your server would only need to understand a reasonably small subset of commands (memory read, register read, possibly threads if your system includes them).