From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8892 invoked by alias); 8 Nov 2002 19:34:33 -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 8876 invoked from network); 8 Nov 2002 19:34:32 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.212.31) by sources.redhat.com with SMTP; 8 Nov 2002 19:34:32 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 19B26357E; Fri, 8 Nov 2002 11:34:32 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id gA8JYVB05781; Fri, 8 Nov 2002 11:34:31 -0800 Date: Fri, 08 Nov 2002 11:34:00 -0000 Message-Id: <200211081934.gA8JYVB05781@magilla.sf.frob.com> From: Roland McGrath To: davidm@hpl.hp.com Cc: libc-hacker@sources.redhat.com Subject: Re: patch to make init_array work (2nd version; resend) X-Shopping-List: (1) Buy & Break Horsie malnutrition (2) Cenozoic Loads (3) Mysterious wavechords (4) Defiant casino erosion X-SW-Source: 2002-11/txt/msg00041.txt.bz2 When this approach came up before, Ulrich also objected to the implementation, see http://sources.redhat.com/ml/libc-alpha/2002-03/msg00063.html. In future repostings of patches previously discussed, it would be helpful if you could cite the prior posting and discussion in the mailing list archives, for the benefit of people like me who were not involved in the discussion the first time around. For dynamic executables, the dynamic linker or libc could in fact examine the DT_INIT_ARRAY slots directly, rather than having the crt1.o code supply the values. I think this is what Ulrich wanted to see from what he said in the message cited above. The same is true of DT_INIT/DT_FINI, but for whatever reason the convention inherited from SVR4 is to have the startup code call its own _init and _fini entry points rather than the dynamic linker doing it. That suggested approach is not available for static linking, however. We need to keep the same crt1.o code for both static and dynamic linking (or else all go raving mad). So it is not entirely clear to me what exact criteria the ideal solution should meet. I am inclined to think the plan we discussed yesterday is the best one. But if Ulrich prefers to have ld.so or libc look up DT_INIT_ARRAY et al, then I would like to hear his thoughts on the plan for static linking. Thanks, Roland