From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18929 invoked by alias); 13 Jun 2003 15:48:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9500 invoked from network); 13 Jun 2003 15:44:24 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 13 Jun 2003 15:44:24 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8FC252B5F; Fri, 13 Jun 2003 11:44:19 -0400 (EDT) Message-ID: <3EE9F153.50605@redhat.com> Date: Fri, 13 Jun 2003 15:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb Subject: Re: examining remote core dumps; MT support for attach; References: <3EE91D2E@webmail.drexel.edu> <20030613131911.GA29641@nevyn.them.org> <3EE9D22B.1060300@redhat.com> <20030613133905.GD29641@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00253.txt.bz2 > On Fri, Jun 13, 2003 at 09:31:23AM -0400, Andrew Cagney wrote: > >> >On Thu, Jun 12, 2003 at 05:17:03PM -0400, nak26 wrote: >> > > >> >>>> How hard would it be to add support for that? I can give it a try, but > >> > > >> >>would > >> > > >> >>>> need some guidance... > >> > > >> >>> >> >>>I have no idea how you would do it. You'd have to transfer essentially >> >>>the same info anyway. Or port gdbserver to have a "core file" target >> >>>but I don't know how well that would work. > >> > > >> >> >> >>What do you mean by "Or port gdbserver to have a "core file" target >> >>but I don't know how well that would work"? > >> > >> > >> >Allow gdbserver to read from a core file instead of a running process. >> >It would be tricky; you'll have to figure out how to do it yourself. > >> >> There was a suggestion made that GDB could manipulate files on the >> remote system (mainly to get at /proc/auxv). Such a mechanism would >> also address the core file problem. > > > This is a reasonable idea, but I think our current remote protocol is > not quite up to the task. Let's keep it on the list along with > multiple channels (for I/O) and file upload/download... qPread;FILE,OFFSET,LENGTH qPwrite:FILE,OFFSET,DATA Andrew