1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
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 <bfd.h>
#include <sysdep.h>
#include <libbfd.h>
/*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++;
}
}
|
