From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 417 invoked by alias); 5 Jan 2006 03:24:23 -0000 Received: (qmail 397 invoked by uid 22791); 5 Jan 2006 03:24:22 -0000 X-Spam-Check-By: sourceware.org Received: from smtp7.wanadoo.fr (HELO smtp7.wanadoo.fr) (193.252.22.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 03:24:20 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0709.wanadoo.fr (SMTP Server) with ESMTP id 6E9641C0009C for ; Thu, 5 Jan 2006 04:24:16 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-21-12.w81-248.abo.wanadoo.fr [81.248.233.12]) by mwinf0709.wanadoo.fr (SMTP Server) with ESMTP id D2FCD1C00088; Thu, 5 Jan 2006 04:23:16 +0100 (CET) X-ME-UUID: 20060105032327864.D2FCD1C00088@mwinf0709.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id D0D6647E7B; Thu, 5 Jan 2006 07:22:32 +0400 (RET) Date: Thu, 05 Jan 2006 03:24:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: How to implement gcore on pa-hpux ? Message-ID: <20060105032232.GB4734@adacore.com> References: <20060104174009.GC1868@adacore.com> <20060104184050.GA8927@nevyn.them.org> <43BC1DFF.2080501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BC1DFF.2080501@redhat.com> User-Agent: Mutt/1.4i 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/msg00055.txt.bz2 > 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] } This is why I'm suggesting that the part that writes the core file become a method. That way, we can have several types of gcore implementations. One variation of your proposal is maybe to extract out the part that writes the core file from gcore.c, move it to gcore-elf.c (is this elf only????), and then have a gcore-hpux.c. I'm not too fond of this approach, though, because eventually we want to be able to have support for multiple targets in the same debugger. Say we have a HP/UX native debugger that also supports a target that the current gcore module supports. We'd have to choose one or the other, but we couldn't have both. -- Joel