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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
<html>
<title>
gccld
</title>
<body>
<center>
<h1>Low Level Virtual Machine</h1>
</center>
<HR>
<h3>
NAME
</h3>
gccld
<h3>
SYNOPSIS
</h3>
gccld [options] < filename> [ filename ...]
<h3>
DESCRIPTION
</h3>
The gccld utility takes a set of LLVM bytecode files and links them together
into a single LLVM bytecode file. The output bytecode file can be another
bytecode library or an executable bytecode program. Using additional options,
gccld is able to produce native code executables.
<p>
The gccld utility is primarily used by the GCC front end, and as such, attempts
to mimic the interface provided by the default system linker so that it can act
as a "drop-in" replacement.
<h4>
Search Order
</h4>
When looking for objects specified on the command line, gccld will search for
the object first in the current directory and then in the directory specified
by LLVM_LIB_SEARCH_PATH. If it cannot find the object, it fails.
<p>
When looking for a library specified with the -l option, gccld first attempts
to load a file with that name from the current directory. If that fails, it
looks for lib<library>.bc, lib<library>.a, or
lib<library>.so, in that order, in each directory added to the library
search path with the -L option. These directories are searched in order they
were specified. If the library cannot be located, then gccld looks in the
directory specified by the LLVM_LIB_SEARCH_PATH environment variable. If it
does not find lib<library>.[bc | a | so] there, it fails.
The -L option is global. It does not matter where it is specified in the list
of command line arguments; the directory is simply added to the search path and
is applied to all libraries, preceding or succeeding, in the command line.
<h4>
Link order
</h4>
All object files are linked first in the order they were specified on the
command line. All library files are linked next. Some libraries may not be
linked into the object program; see below.
<h4>
Library Linkage
</h4>
Object files and static bytecode objects are always linked into the output
file. Library archives (.a files) load only the objects within the archive
that define symbols needed by the output file. Hence, libraries should be
listed after the object files and libraries which need them; otherwise, the
library may not be linked in, and the dependent library will not have its
undefined symbols defined.
<h4>
Native code generation
</h4>
The gccld program has limited support for native code generation.
<h3>
OPTIONS
</h3>
<ul>
<li> -help
<br>
Print a summary of command line options.
<p>
<li> -o <filename>
<br>
Specify the output filename which will hold the linked bytecode.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
<li> -verify
<br>
Verify each pass result.
<p>
<li> -L=<directory>
<br>
Add directory to the list of directories to search when looking for
libraries.
<p>
<li> -disable-internalize
<br>
Do not mark all symbols as internal.
<p>
<li> -internalize-public-api-file <filename>
<br>
Preserve the list of symbol names in the file filename.
<p>
<li> -internalize-public-api-list <list>
<br>
Preserve the symbol names in list.
<p>
<li> -l=<library>
<br>
Specify libraries to include when linking the output file. When linking,
gccld will first attempt to load a file with the pathname library. If that
fails, it will then attempt to load lib<library>.bc,
lib<library>.a, and lib<library>.so, in that order.
<p>
<li> -link-as-library
<br>
Link the .bc files together as a library, not an executable.
<p>
<li> -native
<br>
Generate a native, machine code executable.
<p>
When generating native executables, gccld first checks for a bytecode version
of the library and links it in, if necessary. If the library is missing,
gccld skips it. Then, gccld links in the same libraries as native code.
<p>
In this way, gccld should be able to link in optimized bytecode subsets of
common libraries and then link in any part of the library that hasn't been
converted to bytecode.
<p>
<li> -s
<br>
Strip symbol information from the generated executable.
<p>
<li> -v
<br>
Print information about actions taken.
</ul>
<h3>
EXIT STATUS
</h3>
If gccld succeeds, it will exit with 0. Otherwise, if an error occurs, it
will exit with a non-zero value.
<h3>
SEE ALSO
</h3>
gccas
<h3>
BUGS
</h3>
The -L option cannot be used for find native code libraries when using the
-native option.
<HR>
<a href="http://llvm.cs.uiuc.edu">LLVM Team</a>
</body>
</html>
|