From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31329 invoked by alias); 6 Jan 2006 04:40:27 -0000 Received: (qmail 31322 invoked by uid 22791); 6 Jan 2006 04:40:27 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 04:40:26 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k064eObC031994 for ; Thu, 5 Jan 2006 23:40:24 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k064eO131030; Thu, 5 Jan 2006 23:40:24 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k064eH5N028847; Thu, 5 Jan 2006 23:40:22 -0500 Message-ID: <43BDF489.1080600@redhat.com> Date: Fri, 06 Jan 2006 04:40:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Joel Brobecker CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: How to implement gcore on pa-hpux ? References: <20060104174009.GC1868@adacore.com> <20060104184050.GA8927@nevyn.them.org> <43BC1DFF.2080501@redhat.com> <20060105032232.GB4734@adacore.com> In-Reply-To: <20060105032232.GB4734@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00070.txt.bz2 Joel Brobecker wrote: >>The "gcore" command is actually defined in gcore.c. If someone >>(hpux) wanted to define it differently, it should be as simple as >>linking in your own (eg.) hpux-gcore.c module, *instead of* the >>generic gcore.c module. >> >>Current targets that implement gcore in the generic way >>do so by adding gcore.o to the NATDEPFILES. > > > That's almost the approach I took. The problem with the above > is that you end up rewriting a bunch of code that could have > been reused (namely the code that adds the "gcore" command, > and the part of gcore_command that deals with arguments). > > If you really want to know, I did > > gcore_command (...) > { > [part that deals with arguments] > > #ifdef HAVE_TTRACE > dump_core_file (...); > return; > #endif > > [rest of the regular gcore_command] > } OK, well, without looking at your code I don't know if this is applicable, but I did write the gcore code so as to use callbacks. It was intended to be extendable, so that whatever needed to be done per-section(segment) could be done by the callbacks, which you could supply. The callbacks supplied are for elf, for instance, which is the only object format that I directly addressed, but I would hope that callbacks for other formats could be made to fit. I was intending, for instance, to implement a callback for remote targets that would simply read the memory from the remote-writeable sections and copy it into a file. Can this not be made to work for you?