From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19911 invoked by alias); 7 Nov 2002 22:32:50 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 19895 invoked from network); 7 Nov 2002 22:32:49 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 7 Nov 2002 22:32:49 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id OAA05655; Thu, 7 Nov 2002 14:32:49 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with ESMTP id gA7MWmL29333; Thu, 7 Nov 2002 14:32:48 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian -4) with ESMTP id gA7MWmHW023354; Thu, 7 Nov 2002 14:32:48 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian -4) id gA7MWmnf023350; Thu, 7 Nov 2002 14:32:48 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.59920.66031.178917@napali.hpl.hp.com> Date: Thu, 07 Nov 2002 14:32:00 -0000 To: Roland McGrath Cc: davidm@hpl.hp.com, libc-hacker@sources.redhat.com Subject: Re: [PATCH] move __gmon_start__ call out of .init section In-Reply-To: <200211072227.gA7MRZq29175@magilla.sf.frob.com> References: <15818.58477.531836.650663@napali.hpl.hp.com> <200211072227.gA7MRZq29175@magilla.sf.frob.com> Reply-To: davidm@hpl.hp.com X-SW-Source: 2002-11/txt/msg00031.txt.bz2 >>>>> On Thu, 7 Nov 2002 14:27:35 -0800, Roland McGrath said: >> The problem is that the unwind info for the .init/.fini section >> will be incorrect if it contains any function call. Roland> I don't really see why it should matter for these functions Roland> (when do you unwind through them?), but I can take your word Roland> for it that it does. It matters during debugging for example (that's how I originally found the problem). There are other reasons. For example, a profiling tool might want to periodically create a stack trace to create call-graph profiles. Roland> It's a weak reference and so might be zero. There is no Roland> provision in the spec for preinit_array elements being zero, Roland> so it would be questionable to have it skip them (rather Roland> than a user putting a random zero into the array getting the Roland> crash he deserves). We wouldn't be putting __gmon_init__ directly into .preinit---we would put a function there which will then check whether __gmon_init__ is NULL and, if not, call it. Roland> It sounds like this is really an ia64-specific issue and so Roland> there isn't any question of wanting to do this for the other Roland> platforms. So I will put your change in. OK, thanks. Roland> Please fix whatever you are using to munge your diffs so Roland> that it produces correct file names instead of the garbage Roland> all your recent patches have contained. After today I won't Roland> be in the mood to manually unmunge patches that can't be Roland> applied by any single -pN setting. Hmmh, I'm sorry about that. I was using a script that Uli sent me some time ago. I'm not a (heavy) CVS user but Uli told me that the patches created by "cvs diff -U" are broken. What's the recommend way to create a diff from the glibc CVS? --david