From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31951 invoked by alias); 12 Jan 2006 05:55:38 -0000 Received: (qmail 31943 invoked by uid 22791); 12 Jan 2006 05:55:37 -0000 X-Spam-Check-By: sourceware.org Received: from smtp12.wanadoo.fr (HELO smtp12.wanadoo.fr) (193.252.22.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jan 2006 05:55:36 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1212.wanadoo.fr (SMTP Server) with ESMTP id 6246E1C00095 for ; Thu, 12 Jan 2006 06:55:33 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-26-63.w81-248.abo.wanadoo.fr [81.248.238.63]) by mwinf1212.wanadoo.fr (SMTP Server) with ESMTP id B71861C000A2; Thu, 12 Jan 2006 06:55:32 +0100 (CET) X-ME-UUID: 20060112055532750.B71861C000A2@mwinf1212.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id DD02B47E7B; Thu, 12 Jan 2006 09:55:29 +0400 (RET) Date: Thu, 12 Jan 2006 05:55:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] implement gcore on hp/ux Message-ID: <20060112055529.GJ676@adacore.com> References: <20060110171752.GL925@adacore.com> <200601102029.k0AKTfPh011880@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601102029.k0AKTfPh011880@elgar.sibelius.xs4all.nl> 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/msg00121.txt.bz2 Mark, > I'm not sure I like the exec_set_write_core_file() hack. Targets > should really do this the proper way, initializing their target vector > properly. Can't you get rid of it by setting to_write_core_file in > procfs.c:init_ptoc_ops() and linux-nat.c:linux_target()? I ran into something I didn't expect. Doing the above for all linux targets was easy; so was it for all freebsd targets. But I still have to work on the following ones (names of mh files): . i386/i386sol2 . i386/sol2-64 . sparc/sol2 . i386/i386v42mp . s390/s390 All the above configurations currently include gcore. I started working on i386sol2, and found out that the target vector for this configuration seems to be the procfs one. In the rest of this discussion, I will refer to "the" target vector as the one at the process stratum. For Linux and FreeBSD, it was easy because the nat files were always creating their own target vector based on the ptrace one. The ptrace target vector was never pushed on the target stack. However, so far, the procfs target vector IS pushed on the target stack, and no modification has been needed so far. But if we are to continue in this direction, we will need to be able to modify this target vector. I was less and less convinced by the entire idea of using the target vector, at least for such a minor extension to GDB just for HP/UX. Perhaps a few lines of code duplication in inf-ttrace wouldn't be so bad. Except that it might be a good general cleanup for GDB. For instance, I really like the model used by Linux for instance, where they use a default target vector provided by inf-ptrace, and tailor it to their needs. Would it make sense to modify the procfs support such that it is no longer pushed itself on the stack, but instead used as a tailorable template? I'm sure we can find ways to scrub directly inside the procfs target vector, but this would seem rather ugly to me. The whole patch is becoming too big in my opinion to be submitted in one go. If we agree on continuing on this path, then I will submit one or more preparatory patches (such as making the procfs target vector a template for instance), as needed. Thanks, -- Joel