From owner-freebsd-hackers Mon Dec 28 05:20:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA00794 for freebsd-hackers-outgoing; Mon, 28 Dec 1998 05:20:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ics.com (ics.com [140.186.40.192]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00789 for ; Mon, 28 Dec 1998 05:20:16 -0800 (PST) (envelope-from kaleb@ics.com) Received: from kaleb.keithley.belmont.ma.us (pmdialin5.ics.com [140.186.40.179]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id IAA13577 Mon, 28 Dec 1998 08:19:58 -0500 (EST) Received: from kaleb.keithley.belmont.ma.us (localhost [127.0.0.1]) by kaleb.keithley.belmont.ma.us (8.9.1/8.9.1) with SMTP id JAA09005 for ; Mon, 28 Dec 1998 09:45:06 -0500 (EST) (envelope-from kaleb@ics.com) Message-ID: <3687996E.63DECDAD@ics.com> Date: Mon, 28 Dec 1998 09:45:02 -0500 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: ld (bfd): wrong function names for ELF shared library DT_{INIT,FINI} References: <199812280523.VAA08366@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > In article <36869BCF.2F1CF0FB@ics.com>, > Kaleb S. KEITHLEY wrote: > > > > > > > > What is named ".init" and ".fini" are the **section** where these > > > > functions are placed in. This are not the function names. In fact, > > > > the function names are not specified at all. _init and _fini come > > > > from folklore (speek, the first ELF implementations). > > > > > > I haven't looked at the i386 code but the alpha _init() and _fini() are > > > already in the correct sections. > > > > On x86 ELF binutils/ld does not create .init or .fini sections. > > Nor does it need to. Nor should it. That's taken care of by the > various crt*.o modules in /usr/lib. That's not what's wanted. If a shared library is created with cc, which pulls in /usr/lib/crti.o, then we get the .init and .fini sections, plus no-op _init() and _fini() functions. That's bad if I've written my own _init() and _fini() functions then I get multiple definitions and the link fails. Those no-op functions don't even have returns. What happens if something tries to call them? Apparently the rtld is smart enough not to call them if they're zero length??? If I create the shared library with ld (and deliberately don't link crti.o), then I don't get .init and .fini sections. Right now it doesn't seem to hurt anything. Perhaps the _init() and _fini functions in crti.S need to be weak symbols. Otherwise if I want my own _init() and _fini() funcions and I'm being pedantic and want them in .init and .fini sections, I have to resort to compile-to-assembler, edit, and assemble in order to accomplish that. > > > In the past, given the lack of tools to tag things as belonging in > > the .init and .fini sections that I have kludged it with assembler > > to create .init() and .fini() functions, and they were called. Given > > that the .init and .fini sections are simply executable code, I > > think the distinction between being sections and being functions is > > too subtle to support your case. > > There is nothing subtle about the difference between sections and > functions. I did not say that the difference between sections and functions was subtle. I said the difference between __these__ two sections and functions was subtle. .init and .fini sections are __special__ sections. The spec says they point to executable code. A function label points to executable code too. As such the distinction between them seems subtle. And as I recall, circa Solaris 2.3, functions named .init() and .fini() in a shared library would be called. I don't have a 2.3 system to retry this, and it doesn't work on 2.4, so it's moot. -- Kaleb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message