From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8954 invoked by alias); 6 Jan 2006 10:28:37 -0000 Received: (qmail 8945 invoked by uid 22791); 6 Jan 2006 10:28:36 -0000 X-Spam-Check-By: sourceware.org Received: from smtp11.wanadoo.fr (HELO smtp11.wanadoo.fr) (193.252.22.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 10:28:34 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1102.wanadoo.fr (SMTP Server) with ESMTP id 032FA1C0005D for ; Fri, 6 Jan 2006 11:28:30 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-23-76.w81-248.abo.wanadoo.fr [81.248.235.76]) by mwinf1102.wanadoo.fr (SMTP Server) with ESMTP id 86E081C0005B; Fri, 6 Jan 2006 11:28:29 +0100 (CET) X-ME-UUID: 20060106102829552.86E081C0005B@mwinf1102.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 4300C47E7B; Fri, 6 Jan 2006 14:28:24 +0400 (RET) Date: Fri, 06 Jan 2006 10:28: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: <20060106102824.GQ4734@adacore.com> References: <20060104174009.GC1868@adacore.com> <20060104184050.GA8927@nevyn.them.org> <43BC1DFF.2080501@redhat.com> <20060105032232.GB4734@adacore.com> <43BDF489.1080600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BDF489.1080600@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/msg00073.txt.bz2 > 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? I think I see what you mean, and I now understand the reason for the callbacks. I suppose I could do the same for HP/UX, but it would be more work than just relying on ttrace. The discussion started because I thought it would be a shame to duplicate a few lines of code. But perhaps there is another way of dealing with this. 1. Create a new file gcore-elf.c Move the elf section there. 2. Create a new file gcore-hpux.c Put the hpux code there 3. Have gcore call a predefined routine, or maybe a hook specified by the gcore-* module. It's not as elegant as having a gdbarch or target method, but it's probably easier to implement. We defer a bit the work that makes this a method of some vector, but it's not necessary right now. Perhaps the pragmatic thing to do would be to wait until we need it before we start worrying about it. Even then, the work is slightly prepared because we already have the genericity based on the hook. What do you guys think? -- Joel