From owner-freebsd-hackers Mon Dec 28 09:57:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25615 for freebsd-hackers-outgoing; Mon, 28 Dec 1998 09:57:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA25602 for ; Mon, 28 Dec 1998 09:57:39 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id JAA00413; Mon, 28 Dec 1998 09:57:03 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id JAA09526; Mon, 28 Dec 1998 09:57:03 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 28 Dec 1998 09:57:03 -0800 (PST) Message-Id: <199812281757.JAA09526@vashon.polstra.com> To: kaleb@ics.com Subject: Re: ld (bfd): wrong function names for ELF shared library DT_{INIT,FINI} Newsgroups: polstra.freebsd.hackers In-Reply-To: <3687996E.63DECDAD@ics.com> References: <199812280523.VAA08366@vashon.polstra.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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. You are not supposed to write your own _init() and _fini() functions directly, nor do you need to (see below). Those symbols are reserved to the implementation. Look up "reserved identifiers" in the C standard if you want the gory details. > Those no-op functions don't even have returns. Yes they do. Look at "src/lib/csu/i386-elf/crtn.S". This whole thread is pretty frustrating. You have been jumping to conclusions and throwing misinformation onto the mailing lists. How about slowing down and understanding the code first? Or at least phrase your conjectures as questions, so as not to confuse the innocent bystanders. > 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. No, there are several ways to do it. Read about "function attributes" in the gcc info pages. Probably the easiest way to get what you want is like this: void myinit(void) __attribute__ ((constructor)); void myfini(void) __attribute__ ((destructor)); void myinit(void) { /* My initialization code. */ } void myfini(void) { /* My finalization code. */ } > > > 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. More misinformation. The spec does _not_ say that .init and .fini point to executable code. It says this: .init This section holds executable instructions that contribute to the process initialization code. That is, when a program starts to run, the system arranges to execute the code in this section before calling the main program entry point (called "main" for C programs). There is similar verbiage in the description of .fini, which I won't bother quoting here. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message