From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15261 invoked by alias); 4 Jan 2006 18:40:55 -0000 Received: (qmail 15253 invoked by uid 22791); 4 Jan 2006 18:40:55 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 04 Jan 2006 18:40:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EuDZ4-0002Km-HE; Wed, 04 Jan 2006 13:40:50 -0500 Date: Wed, 04 Jan 2006 18:40:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: How to implement gcore on pa-hpux ? Message-ID: <20060104184050.GA8927@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20060104174009.GC1868@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060104174009.GC1868@adacore.com> User-Agent: Mutt/1.5.8i 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/msg00045.txt.bz2 On Wed, Jan 04, 2006 at 09:40:09PM +0400, Joel Brobecker wrote: > > So I created a new function in infttrace.c. In order to avoid re-writing > the part of gcore.c that add the command, and handles the arguments of this > command, I simply hooked the new infttrace directly into the gcore code. > A bit crude, but it works and it's pretty localized. > > For the FSF tree, I'd like to implement this a little better, and it > seems to me that the core part of this command, the part that actually > creates the core file, should be a method of some vector. But which > vector? > > The way the gcore command is currently written, it seems that it would > make sense for it to be part of the target vector. No? > > However, in the case of HP/UX, there is a slight complication, because > the method is only good in the native case... If you really mean target vector, then this isn't a complication at all. The native case should have its own target vector already, in inf-ttrace.c (note the dash in modern sources). Ideally remote targets could gcore; but there's been no interest in implementing that so far, so it's not worth concerning ourselves with until someone wants to work on it. -- Daniel Jacobowitz CodeSourcery