From e5e193c74278661e91c1d1748571c8a8380541e7 Mon Sep 17 00:00:00 2001 From: Steve Chamberlain Date: Sat, 2 Nov 1991 22:37:07 +0000 Subject: Initial revision --- bfd/ctor.c | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 bfd/ctor.c (limited to 'bfd') diff --git a/bfd/ctor.c b/bfd/ctor.c new file mode 100644 index 0000000..6593373 --- /dev/null +++ b/bfd/ctor.c @@ -0,0 +1,144 @@ +/* BFD library support routines for constructors + Copyright (C) 1990-1991 Free Software Foundation, Inc. + + Hacked by Steve Chamberlain of Cygnus Support. With some help from + Judy Chamberlain too. + + +This file is part of BFD, the Binary File Descriptor library. + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ + +/*doc* +@section Constructors +Classes in C++ have 'constructors' and 'destructors'. These are +functions which are called automatically by the language whenever data +of a class is created or destroyed. Class data which is static data +may also be have a type which requires 'construction', the contructor +must be called before the data can be referenced, so the contructor +must be called before the program begins. + +The common solution to this problem is for the compiler to call a +magic function as the first statement @code{main}. This magic +function, (often called @code{__main}) runs around calling the +constructors for all the things needing it. + +With COFF the compile has a bargain with the linker et al. All +constructors are given strange names, for example +@code{__GLOBAL__$I$foo} might be the label of a contructor for the +class @var{foo}. The solution on unfortunate systems (most system V +machines) is to perform a partial link on all the .o files, do an +@code{nm} on the result, run @code{awk} or some such over the result +looking for strange @code{__GLOBAL__$} symbols, generate a C program +from this, compile it and link with the partially linked input. This +process is usually called @code{collect}. + +Some versions of @code{a.out} use something called the +@code{set_vector} mechanism. The constructor symbols are output from +the compiler with a special stab code saying that they are +constructors, and the linker can deal with them directly. + +BFD allows applications (ie the linker) to deal with constructor +information independently of their external implimentation by +providing a set of entry points for the indiviual object back ends to +call which maintains a database of the contructor information. The +application can interrogate the database to find out what it wants. + +The construction data essential for the linker to be able to perform +its job are: + +@itemize @bullet +@item asymbol +The asymbol of the contructor entry point contains all the information +necessary to call the function. +@item table id +The type of symbol, ie is it a contructor, a destructor or something +else someone dreamed up to make our lives difficult. +@end itemize + +This module takes this information and then builds extra sections +attached to the bfds which own the entry points. It creates these +sections as if they were tables of pointers to the entry points, and +builds relocation entries to go with them so that the tables can be +relocated along with the data they reference. + +These sections are marked with a special bit (@code{SEC_CONSTRUCTOR}) +which the linker notices and do with what it wants. + + +*/ + +#include +#include +#include + + + +/*proto-internal* bfd_constructor_entry + +This function is called with an a symbol describing the +function to be called, an string which descibes the xtor type, eg +something like "CTOR" or "DTOR" would be fine. And the bfd which owns +the function. + +It's duty is to create a section called "CTOR" or "DTOR" or whatever +if the bfd doesn't already have one, and grow a relocation table for +the entry points as they accumulate. + + +*; PROTO(void, bfd_constructor_entry, + (bfd *abfd, + asymbol **symbol_ptr_ptr, + CONST char*type); + +*/ + + +void DEFUN(bfd_constructor_entry,(abfd, symbol_ptr_ptr, type), + bfd *abfd AND + asymbol **symbol_ptr_ptr AND + CONST char *type) + +{ + /* Look up the section we're using to store the table in */ + asection *rel_section = bfd_get_section_by_name (abfd, type); + if (rel_section == (asection *)NULL) { + rel_section = bfd_make_section (abfd, type); + rel_section->flags = SEC_CONSTRUCTOR; + rel_section->alignment_power = 2; + } + + /* Create a relocation into the section which references the entry + point */ + { + arelent_chain *reloc = (arelent_chain *)bfd_alloc(abfd, + sizeof(arelent_chain)); + + reloc->relent.section = (asection *)NULL; + reloc->relent.addend = 0; + + reloc->relent.sym_ptr_ptr = symbol_ptr_ptr; + reloc->next = rel_section->constructor_chain; + rel_section->constructor_chain = reloc; + reloc->relent.address = rel_section->size; + /* ask the cpu which howto to use */ + reloc->relent.howto = + bfd_reloc_type_lookup(abfd->arch_info, + BFD_RELOC_CTOR); + rel_section->size += sizeof(int *); + rel_section->reloc_count++; + } + +} -- cgit v1.1