From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29500 invoked by alias); 11 Jan 2006 03:59:39 -0000 Received: (qmail 29491 invoked by uid 22791); 11 Jan 2006 03:59:39 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.wanadoo.fr (HELO smtp1.wanadoo.fr) (193.252.22.30) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jan 2006 03:59:37 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0104.wanadoo.fr (SMTP Server) with ESMTP id 0FDB91FFFFBA for ; Wed, 11 Jan 2006 04:59:33 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-8-38.w81-248.abo.wanadoo.fr [81.248.195.38]) by mwinf0104.wanadoo.fr (SMTP Server) with ESMTP id ABE021FFFFAB; Wed, 11 Jan 2006 04:59:32 +0100 (CET) X-ME-UUID: 20060111035932704.ABE021FFFFAB@mwinf0104.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id A2ED947E7B; Wed, 11 Jan 2006 07:59:29 +0400 (RET) Date: Wed, 11 Jan 2006 03:59:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] implement gcore on hp/ux Message-ID: <20060111035929.GF878@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/msg00109.txt.bz2 > 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()? Yes, absolutely. I think I also need to do that for FreeBSD and probably Solaris too (IIRC), right? > The HP-UX code looks good, but could you please use xsnprintf() > instead of sprintf()? Oops, good catch. Will fix that as well. Thanks for the review. -- Joel