From libc-hacker-return-5802-listarch-libc-hacker=sourceware dot cygnus dot com at sources dot redhat dot com Thu Nov 07 21:51:38 2002 Return-Path: Delivered-To: listarch-libc-hacker at sourceware dot cygnus dot com Received: (qmail 28437 invoked by alias); 7 Nov 2002 21:51:38 -0000 Mailing-List: contact libc-hacker-help at sources dot redhat dot com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner at sources dot redhat dot com Delivered-To: mailing list libc-hacker at sources dot redhat dot com Received: (qmail 28411 invoked from network); 7 Nov 2002 21:51:37 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources dot redhat dot com with SMTP; 7 Nov 2002 21:51:37 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos dot hpl dot hp dot com (8 dot 9 dot 3 (PHNE_24419)/HPL-PA Relay) with ESMTP id NAA01520; Thu, 7 Nov 2002 13:51:37 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2 dot hpl dot hp dot com (8 dot 10 dot 2/8 dot 10 dot 2 HPL-PA Hub) with ESMTP id gA7LpaL26802; Thu, 7 Nov 2002 13:51:36 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali dot hpl dot hp dot com (8 dot 12 dot 3/8 dot 12 dot 3/Debian -4) with ESMTP id gA7LpaHW022872; Thu, 7 Nov 2002 13:51:36 -0800 Received: (from davidm@localhost) by napali dot hpl dot hp dot com (8 dot 12 dot 3/8 dot 12 dot 3/Debian -4) id gA7LpVIB022866; Thu, 7 Nov 2002 13:51:31 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.57443.807212.759018@napali.hpl.hp.com> Date: Thu, 7 Nov 2002 13:51:31 -0800 To: Roland McGrath Cc: davidm at hpl dot hp dot com, libc-hacker at sources dot redhat dot com, hjl at lucon dot org Subject: Re: patch to make init_array work (2nd version; resend) In-Reply-To: <200211072131 dot gA7LVdj28886 at magilla dot sf dot frob dot com> References: <15818.49752.477001.832523@napali.hpl.hp.com> <200211072131 dot gA7LVdj28886 at magilla dot sf dot frob dot com> Reply-To: davidm at hpl dot hp dot com >>>>> On Thu, 7 Nov 2002 13:31:39 -0800, Roland McGrath said: Roland> Your dl-fini.c fix is obviously correct and I put that in. Great! Thanks a lot! Roland> None of the messages I have seen from you or HJ have Roland> mentioned what the problem being fixed by HJ's changes was, Roland> so I had to look at the whole thing for a while to figure Roland> out what the point was. (The arrays are already processed Roland> properly in loaded objects, but not in the executable Roland> itself.) Now that I see the problem, I can at least put in Roland> those test cases. Sorry, I think neither HJ nor I were trying to be cryptic. Yes, the main problem is indeed that .init_array/.fini_array don't get called for the main program (though HJ's patch obviously address other things as well, such as correcting the order of .fini_array calls and adding test case). Roland> I don't like HJ's implementation, which introduces three new Roland> relocs in libc.so with weak references to symbols defined in Roland> crt1.o. That's just nasty. The simple thing would be to Roland> pass more arguments to __libc_start_main, which would Roland> require versioning. Roland> But I think that, in keeping with the convention that its Roland> own .init/.fini are the executable's problem, it would be Roland> cleanest for the arrays just to be handled by the existing Roland> init/fini functions in the executable. That is, have the Roland> single function pair it passes (now _init/_fini) do all the Roland> work. My first thought was to just put the code into Roland> crti.o/crtn.o, but this code should not go into shared Roland> libraries. OK, I _think_ I understand your concern. Perhaps we could just change the platform-specific start.S to pass a different _init/_fini function which takes care of calling init_array/fini_array? If you think that would work, I can take a stab at doing that for sysdeps/ia64/elf/start.S. Thanks, --david