Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Dec 1998 09:57:03 -0800 (PST)
From:      John Polstra <jdp@polstra.com>
To:        kaleb@ics.com
Cc:        hackers@FreeBSD.ORG
Subject:   Re: ld (bfd): wrong function names for ELF shared library  DT_{INIT,FINI}
Message-ID:  <199812281757.JAA09526@vashon.polstra.com>
In-Reply-To: <3687996E.63DECDAD@ics.com>
References:  <Pine.BSF.4.01.9812271747560.383-100000@herring.nlsystems.com> <199812280523.VAA08366@vashon.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812281757.JAA09526>