From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14734 invoked by alias); 5 Jan 2006 04:03:55 -0000 Received: (qmail 14726 invoked by uid 22791); 5 Jan 2006 04:03:54 -0000 X-Spam-Check-By: sourceware.org Received: from smtp2.wanadoo.fr (HELO smtp2.wanadoo.fr) (193.252.22.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 04:03:52 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0204.wanadoo.fr (SMTP Server) with ESMTP id 25F341C00234 for ; Thu, 5 Jan 2006 05:03:49 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-18-196.w81-248.abo.wanadoo.fr [81.248.215.196]) by mwinf0204.wanadoo.fr (SMTP Server) with ESMTP id 02E971C00224 for ; Thu, 5 Jan 2006 05:03:48 +0100 (CET) X-ME-UUID: 20060105040348120.02E971C00224@mwinf0204.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 74C9E47E79; Thu, 5 Jan 2006 07:53:11 +0400 (RET) Date: Thu, 05 Jan 2006 04:03:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: How to implement gcore on pa-hpux ? Message-ID: <20060105035311.GC4734@adacore.com> References: <20060104174009.GC1868@adacore.com> <20060104184050.GA8927@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060104184050.GA8927@nevyn.them.org> 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/msg00056.txt.bz2 > 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. I proposed the target vector indeed because I thought that we might want to let remote targets also do a core dump, eventually. Thinking about it more, maybe this wasn't the best approach after all. using the target vector, the native HP/UX case seems to be a no-brainer, which is always nice. Suppose I add a new method to that vector that does core file dumping, however. The problem is: How do we set that method of all the cases where we already support gcore? For instance, i386-linux. Seems to me that this should be done during the tdep initialization phase, where we know what type of architecture we're dealing with. But then, can we lightly manipulate target vectors like this, and has the target vector been set at this point? This is a bit of a gray area for me, at the moment, but I have concerns. On the other hand, setting the method during the tdep initialization phase does suggest that maybe a gdbarch method might be better suited. The current gcore implementation doesn't seem to be depending on anything native, so the gdbarch method seems well suited for it. There is the issue of HP/UX however, because in our case, it's native-only. Setting the new gdbarch method using ttrace code would break the tdep/nat separation. So it leads me to propose the following approach: How about I add two new methods: - 1 new gdbarch method: This would be the prefered method to call when trying to dump a core file. This method would be set to the current implementation in all the configurations where this feature is already supported. - 1 new target method: This would be the fallback method when the gdbarch method is not implemented. Set to null by default, it would be set to ttrace.c:dump_core_file in inf_ttrace_target(). - In all other cases, we tell the user that this function is not implemented on this target. The rationale would be: - If we have a target-dependent implementation, great! Use it. - Otherwise, do we have a native-only implementation (in the target vector)? If yes, then better than nothing, use it. - Otherwise, this feature in unimplemented. Seems plausible? -- Joel