This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __CTOR_LIST__


Tony Kimball <alk@pobox.com> writes:

> Quoth Ian Lance Taylor on , 1 July:
> : 
> : x86 Linux normally uses ELF.  In ELF, global constructors are normally
> : handled by putting the address of the constructor in the .ctors
> : section.  When doing a final link, the compiler will include
> : crtbegin.o and crtend.o in the link.  These will fill in the
> : definition of __CTOR_LIST__.
> : 
> : Try compiling a trivial C++ program with a constructor.  You will see
> : that the compiler puts the address of the global constructor in the
> : .ctors section.
> 
> This looks tantalizingly like the beginning of some very helpful
> information, but I am still missing one crucial piece: How do the
> addresses in the .ctors sections get put into the __CTOR_LIST__?  I
> don't see any code in crtstuff.c to do this, nor have I been able to
> detect collect2 or ld doing this.

They don't get put there.  They are there.

Look closely at crtstuff.c.  Or, in this case, it's actually easier to
look at crtbegin.o and crtend.o.  You will see that crtbegin.o defines
__CTOR_LIST__ in the .ctors section, along with the initial -1
indicating that there is no count.  You will see that crtend.o has the
trailing zero in the .ctors section.

gcc arranges to link crtbegin.o before all other object files and
crtend.o after all other object files.  The effect is that the .ctors
section starts with a definition of __CTOR_LIST__, a -1 word, the
.ctors sections in the other object files, and then a final 0 word.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]