Commit | Line | Data |
---|---|---|
86530b38 AT |
1 | .\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13 |
2 | .\" | |
3 | .\" Standard preamble: | |
4 | .\" ======================================================================== | |
5 | .de Sh \" Subsection heading | |
6 | .br | |
7 | .if t .Sp | |
8 | .ne 5 | |
9 | .PP | |
10 | \fB\\$1\fR | |
11 | .PP | |
12 | .. | |
13 | .de Sp \" Vertical space (when we can't use .PP) | |
14 | .if t .sp .5v | |
15 | .if n .sp | |
16 | .. | |
17 | .de Vb \" Begin verbatim text | |
18 | .ft CW | |
19 | .nf | |
20 | .ne \\$1 | |
21 | .. | |
22 | .de Ve \" End verbatim text | |
23 | .ft R | |
24 | .fi | |
25 | .. | |
26 | .\" Set up some character translations and predefined strings. \*(-- will | |
27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left | |
28 | .\" double quote, and \*(R" will give a right double quote. | will give a | |
29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to | |
30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' | |
31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. | |
32 | .tr \(*W-|\(bv\*(Tr | |
33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' | |
34 | .ie n \{\ | |
35 | . ds -- \(*W- | |
36 | . ds PI pi | |
37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch | |
38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch | |
39 | . ds L" "" | |
40 | . ds R" "" | |
41 | . ds C` "" | |
42 | . ds C' "" | |
43 | 'br\} | |
44 | .el\{\ | |
45 | . ds -- \|\(em\| | |
46 | . ds PI \(*p | |
47 | . ds L" `` | |
48 | . ds R" '' | |
49 | 'br\} | |
50 | .\" | |
51 | .\" If the F register is turned on, we'll generate index entries on stderr for | |
52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index | |
53 | .\" entries marked with X<> in POD. Of course, you'll have to process the | |
54 | .\" output yourself in some meaningful fashion. | |
55 | .if \nF \{\ | |
56 | . de IX | |
57 | . tm Index:\\$1\t\\n%\t"\\$2" | |
58 | .. | |
59 | . nr % 0 | |
60 | . rr F | |
61 | .\} | |
62 | .\" | |
63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes | |
64 | .\" way too many mistakes in technical documents. | |
65 | .hy 0 | |
66 | .if n .na | |
67 | .\" | |
68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). | |
69 | .\" Fear. Run. Save yourself. No user-serviceable parts. | |
70 | . \" fudge factors for nroff and troff | |
71 | .if n \{\ | |
72 | . ds #H 0 | |
73 | . ds #V .8m | |
74 | . ds #F .3m | |
75 | . ds #[ \f1 | |
76 | . ds #] \fP | |
77 | .\} | |
78 | .if t \{\ | |
79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) | |
80 | . ds #V .6m | |
81 | . ds #F 0 | |
82 | . ds #[ \& | |
83 | . ds #] \& | |
84 | .\} | |
85 | . \" simple accents for nroff and troff | |
86 | .if n \{\ | |
87 | . ds ' \& | |
88 | . ds ` \& | |
89 | . ds ^ \& | |
90 | . ds , \& | |
91 | . ds ~ ~ | |
92 | . ds / | |
93 | .\} | |
94 | .if t \{\ | |
95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" | |
96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' | |
97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' | |
98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' | |
99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' | |
100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' | |
101 | .\} | |
102 | . \" troff and (daisy-wheel) nroff accents | |
103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' | |
104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' | |
105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] | |
106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' | |
107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' | |
108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] | |
109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] | |
110 | .ds ae a\h'-(\w'a'u*4/10)'e | |
111 | .ds Ae A\h'-(\w'A'u*4/10)'E | |
112 | . \" corrections for vroff | |
113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' | |
114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' | |
115 | . \" for low resolution devices (crt and lpr) | |
116 | .if \n(.H>23 .if \n(.V>19 \ | |
117 | \{\ | |
118 | . ds : e | |
119 | . ds 8 ss | |
120 | . ds o a | |
121 | . ds d- d\h'-1'\(ga | |
122 | . ds D- D\h'-1'\(hy | |
123 | . ds th \o'bp' | |
124 | . ds Th \o'LP' | |
125 | . ds ae ae | |
126 | . ds Ae AE | |
127 | .\} | |
128 | .rm #[ #] #H #V #F C | |
129 | .\" ======================================================================== | |
130 | .\" | |
131 | .IX Title "MIDASFORMAT 1" | |
132 | .TH MIDASFORMAT 1 "2007-01-08" "perl v5.8.0" "User Contributed Perl Documentation" | |
133 | .SH "NAME" | |
134 | midasformat \- Format for diags recognized by \fBmidas\fR | |
135 | .SH "DESCRIPTION" | |
136 | .IX Header "DESCRIPTION" | |
137 | This document describes the format of diags that can be assembled by | |
138 | \&\fBmidas\fR. Note that this is not a guide for writing diags, since it | |
139 | makes no assumptions about the contents of project-standard include | |
140 | files or boot code. | |
141 | .Sh "Source Languages" | |
142 | .IX Subsection "Source Languages" | |
143 | \&\fBMidas\fR can assemble diags in the following formats: | |
144 | .IP "Augmented Assembly" 4 | |
145 | .IX Item "Augmented Assembly" | |
146 | The main supported source language, denoted with a .s extension on the | |
147 | source file, is an augmented \s-1SPARC\s0 assembly file. By \*(L"augmented\*(R", we | |
148 | refer to several directives used to program the \s-1MMU\s0. These directives | |
149 | are interpreted by \fBmidas\fR, and their presence means that the raw diag, | |
150 | even though it ends in .s, would not be acceptable input to a standard | |
151 | assembler. | |
152 | .Sp | |
153 | An assembly diag should be one file, though it may #include others. A | |
154 | diag may also contain a perl script, used by the simulation framework | |
155 | to do postprocessing on the diag's output. \fBMidas\fR scans a diag for the | |
156 | symbol \*(L"_\|_PERL_\|_\*(R" on a line by itself. If it finds such a symbol, | |
157 | then everything after the _\|_PERL_\|_ line is taken to be a perl script | |
158 | and is not assembled. | |
159 | .IP "\s-1PAL\s0 (perl augmented language)" 4 | |
160 | .IX Item "PAL (perl augmented language)" | |
161 | A diag that ends in a .pal extension is assumed to be written in \s-1PAL\s0 | |
162 | (perl augmented language). The diag is run through the \s-1PAL\s0 | |
163 | preprocessor, and the output of \s-1PAL\s0 should be an augmented assembly | |
164 | file as described above. \fBMidas\fR takes care of running the \s-1PAL\s0 | |
165 | preprocesing phase if the diag ends in .pal. Since \s-1PAL\s0 and assembly | |
166 | diags are treated identically after \s-1PAL\s0 preprocessing, the remainder | |
167 | of the this document discusses only assembly diags. | |
168 | .IP "C" 4 | |
169 | .IX Item "C" | |
170 | The top-level diag file is always an augmented assembly file (or a \s-1PAL\s0 | |
171 | script that generated an augmented assembly file), but there are | |
172 | directives to include C programs in a diag. See the \*(L"High Level Languages\*(R" section. | |
173 | .IP "Object files (.o) and Library files (.a)" 4 | |
174 | .IX Item "Object files (.o) and Library files (.a)" | |
175 | As with C files, raw object (.o) files and static library (.a) files | |
176 | may be included in a diag. See the \*(L"High Level Languages\*(R" | |
177 | section. | |
178 | .IP "Linked Executables" 4 | |
179 | .IX Item "Linked Executables" | |
180 | These can be included as-is in a diag. See the \*(L"\s-1APPLICATION\s0\*(R" | |
181 | section. | |
182 | .Sh "Output Files" | |
183 | .IX Subsection "Output Files" | |
184 | The following output files are generated by \fBmidas\fR: (the names of the | |
185 | output files can be reconfigured, but these are the default names) | |
186 | .IP "\fImem.image\fR" 4 | |
187 | .IX Item "mem.image" | |
188 | The \fImem.image\fR file is the main output of \fBmidas\fR. It contains the | |
189 | initial contents of physical memory in a verilog memory-image format. | |
190 | The format consists lines containing "@<physical_address>", | |
191 | followed by lines of data to write at that address. | |
192 | .IP "\fIdiag.ev\fR" 4 | |
193 | .IX Item "diag.ev" | |
194 | This is an event file generated for vera. Any assembly line that | |
195 | contains a comment that begins with \*(L"$EV\*(R" will generate an entry in | |
196 | this file. \fI\s-1XXX\s0 \- this format should be documented further.\fR | |
197 | .IP "\fIsymbol.tbl\fR" 4 | |
198 | .IX Item "symbol.tbl" | |
199 | This file contains 4 columns: symbol_name, virtual_addres, real | |
200 | address, and physical_address. It exists to support the simulation | |
201 | framework so it can lookup addresses for symbol names. If any of the | |
202 | addresses are inappropriate (such as real address for unmapped | |
203 | sections), it will be represented by 'X'. | |
204 | .IP "\fIdiag.pl\fR" 4 | |
205 | .IX Item "diag.pl" | |
206 | This is a perl script extracted from the diag (i.e., the code after | |
207 | the \*(L"_\|_PERL_\|_\*(R" directive). It is used by the simulation framework to | |
208 | do diag-specific post\-processing. | |
209 | .IP "\fIdiag*.exe\fR" 4 | |
210 | .IX Item "diag*.exe" | |
211 | This is the linked executable built by \fBmidas\fR (the * is the name of | |
212 | the application, if there is a non-default application). It is not | |
213 | used by the simulation framework, but it can be useful, for instance, | |
214 | for disassembly. | |
215 | .SH "BUILD PROCESS" | |
216 | .IX Header "BUILD PROCESS" | |
217 | This section is an overview of how a diag is processed to produce | |
218 | \&\fImem.image\fR. | |
219 | .Sh "Preprocessing" | |
220 | .IX Subsection "Preprocessing" | |
221 | Diags are run through several preprocessing steps that enable complex | |
222 | macro environments to perform diag setup. Such macro environments are | |
223 | not part of \fBmidas\fR and are therefore beyond the scope of this document. | |
224 | .IP "Split perl and assembly" 4 | |
225 | .IX Item "Split perl and assembly" | |
226 | The first preprocessing step is to split the diag into assembly and | |
227 | perl parts. \fBMidas\fR assumes that the diag is entirely assembly | |
228 | unless it encounters the symbol \*(L"_\|_PERL_\|_\*(R" on a line by itself. If it | |
229 | sees this symbol, then everything after it assumed to be a perl | |
230 | script. The output of this phase are files in the build directory: | |
231 | \&\fIdiag.s\fR and, if necessary, \fIdiag.pl\fR. | |
232 | .IP "\fBcpp\fR" 4 | |
233 | .IX Item "cpp" | |
234 | The next step is to run the diag through the C preprocessor. Most | |
235 | diags will #include their boot code and perhaps some project-specific | |
236 | definitions. Diags can also #define symbols before including the boot | |
237 | code to configure its operation. Note that this is a Sun, not a \s-1GNU\s0, | |
238 | preprocessor, which means that \s-1GNU\s0 extensions to cpp (such as | |
239 | preprocessor directives where the '#' isn't in column 1) cannot be | |
240 | used. For information the default include path, consult the \fBmidas\fR | |
241 | man page. The output of this stage is a file in the build directory | |
242 | called \fIdiag.cpp\fR. | |
243 | .IP "\fBm4\fR" 4 | |
244 | .IX Item "m4" | |
245 | After \fBcpp\fR, the diag is processed by \fBm4\fR. This allows macro | |
246 | preprocessing that is substantially more powerful than what is | |
247 | possible with \fBcpp\fR. The content of these macros is | |
248 | project\-specific. The version of \fBm4\fR used by \fBmidas\fR is special in | |
249 | that it was compiled to allow 64\-bit arithmetic via the \f(CW\*(C`mpeval\*(C'\fR | |
250 | directive. The output of this stage is a file in the build directory | |
251 | called \fIdiag.m4\fR. | |
252 | .IP "Sectioning" 4 | |
253 | .IX Item "Sectioning" | |
254 | A diag is made up of sections. Each section may contain a text, data, | |
255 | bss or other segments. The defining characteristic of a section is | |
256 | that each segment is contiguous in the virtual address space (i.e., | |
257 | the text segment is contiguous and so is the data segment, but they | |
258 | need not be contiguous with each other). A section begins with a | |
259 | \&\f(CW\*(C`SECTION\*(C'\fR directive at the beginning of a line. The \f(CW\*(C`SECTION\*(C'\fR line | |
260 | defines the section's name and optionally some parameters. Any data | |
261 | or code appearing after a \f(CW\*(C`SECTION\*(C'\fR directive belongs to that | |
262 | section, until the next \f(CW\*(C`SECTION\*(C'\fR directive is encountered. Any code | |
263 | or data before the first \f(CW\*(C`SECTION\*(C'\fR directive is part of the first | |
264 | section. | |
265 | .Sp | |
266 | If a \s-1SECTION\s0 line appears for a section that has previously been | |
267 | defined, the meaning is to append to the existing section. It is | |
268 | illegal to have SECTION-line arguments for any but the first | |
269 | definition of a section. Note that it simply appends to the existing | |
270 | section, so be sure to begin your appended version with a .text or | |
271 | \&.data assembly directive, as appropriate. | |
272 | .Sp | |
273 | Sections are linked at a specific, user-defined address. Linker | |
274 | scripts require that each section be in a separte file. The | |
275 | sectioning phase, therefore, extracts the \f(CW\*(C`SECTION\*(C'\fR directives from | |
276 | the assembly file and writes \*(L"pure\*(R" assembly files for each section. | |
277 | By \*(L"pure\*(R", we mean that these files have no \fBmidas\fR\-specific | |
278 | directives and can therefore be assembled directly. | |
279 | .Sp | |
280 | The output of this phase are a series of files in the build directory, | |
281 | one for each section. Their names are | |
282 | \&\fIsec<num>.<secname>.s\fR. The sectioning phase also | |
283 | produces the file 'diag.midas' which contains all of the midas | |
284 | directives. Midas then parses this file, and leaves the others to the | |
285 | assembler. | |
286 | .Sh "Assembly" | |
287 | .IX Subsection "Assembly" | |
288 | Each section written by the sectioning phase above is assembled via | |
289 | the \s-1GNU\s0 assembler. The output is a .o file. | |
290 | .Sh "Link executable" | |
291 | .IX Subsection "Link executable" | |
292 | All object files are linked, using the \s-1GNU\s0 loader. Each section is | |
293 | linked at the virtual address defined in its section header. The | |
294 | output of this phase is \fIdiag.exe\fR. | |
295 | .Sh "PostProcessing" | |
296 | .IX Subsection "PostProcessing" | |
297 | After the diag is linked, the following postprocessing is done: | |
298 | .IP "Generate \fImem.image\fR" 4 | |
299 | .IX Item "Generate mem.image" | |
300 | Generation of \fImem.image\fR is done a section at a time, not by simply | |
301 | disassembling \fIdiag.exe\fR. The reason is that \fImem.image\fR should | |
302 | represent the initial contents of physical memory, which may or may | |
303 | not be a simple dump of the text and data segments for each section. | |
304 | For most diags, this will simply be a hex dump of \fIdiag.exe\fR (with | |
305 | the sections linked at the appropriate physical addresses, as defined | |
306 | by the section header). How exactly the \s-1MMU\s0 constructs \fImem.image\fR | |
307 | is controlled by the section header, which is described in detail in | |
308 | the next section. Generation of \fImem.image\fR is handled by | |
309 | \&\fBgoldfinger\fR. | |
310 | .IP "Generate \fIsymbol.tbl\fR" 4 | |
311 | .IX Item "Generate symbol.tbl" | |
312 | To generate the symbol table, the \fIdiag.exe\fR file is examined to find | |
313 | virtual addresses for each symbol. The \s-1MMU\s0 is then used to do the | |
314 | virtual-to-physical translation and write the \fIsymbol.tbl\fR file. | |
315 | Generation of \fIsymbol.tbl\fR is handled by \fBgoldfinger\fR. | |
316 | .IP "Generate \fIdiag.ev\fR" 4 | |
317 | .IX Item "Generate diag.ev" | |
318 | The \fIdiag.ev\fR file is generated by examining the diag source for | |
319 | comments containing \f(CW$EV\fR. These are then cross-referenced with | |
320 | \&\fIsymbol.tbl\fR to producde \fIdiag.ev\fR. | |
321 | .SH "DIAG FORMAT" | |
322 | .IX Header "DIAG FORMAT" | |
323 | A diag consists of applications and sections within those | |
324 | applications. Diags may also contain TSBs. | |
325 | .Sh "\s-1APPLICATION\s0" | |
326 | .IX Subsection "APPLICATION" | |
327 | An application begins with: | |
328 | .PP | |
329 | .Vb 1 | |
330 | \& APPLICATION <name> [FILE=<filename>] | |
331 | .Ve | |
332 | .PP | |
333 | An application defines a single linked executable. All SECTIONs that | |
334 | follow are linked into this application. A linked executable is just | |
335 | an intermediate file in \fImem.image\fR generation, so an \s-1APPLICATION\s0 | |
336 | directive affects only relocation and the scope of labels. All diags | |
337 | have at least one application, even if none is defined, since all | |
338 | diags are treated as if their first line were: | |
339 | .PP | |
340 | .Vb 1 | |
341 | \& APPLICATION default | |
342 | .Ve | |
343 | .PP | |
344 | If the optional filename is given, then that file is taken as the | |
345 | linked executable to use. The link path is searched to find a file by | |
346 | this name. This is how you can include a linked executable that was | |
347 | not generated by \fBmidas\fR. | |
348 | .PP | |
349 | \fIgoldfinger_cmd blocks\fR | |
350 | .IX Subsection "goldfinger_cmd blocks" | |
351 | .PP | |
352 | There is currently no way to specify address translations and | |
353 | \&\fImem.image\fR contents for applications that midas does not generate. | |
354 | As the tool matures, I plan to invent an interface. In the meantime, | |
355 | you can include a goldfinger_cmd block. Such a block begins a line | |
356 | with \*(L"goldfinger_cmd\*(R" and an open curly\-brace. It ends with the | |
357 | closed\-curly. The contents of the block are not interpreted \fBmidas\fR | |
358 | at all. They are simply copied into \fIdiag.goldfinger\fR inside the | |
359 | currently open application. | |
360 | .PP | |
361 | An example: | |
362 | .PP | |
363 | .Vb 22 | |
364 | \& goldfinger_cmd { | |
365 | \& BLOCK .main_text_0 | |
366 | \& SECTION_NAME = ".MAIN"; | |
367 | \& SEGMENT_NAME = "text"; | |
368 | \& LINK_SECTION = "sec7.maint"; | |
369 | \& SRC_FILE = "diag.m4"; | |
370 | \& SRC_LINE = 5398; | |
371 | \& COMPRESS = 0; | |
372 | \& VA = 0x0000000020000000; | |
373 | \& RA = 0x0130000000; | |
374 | \& PA = 0x1130000000; | |
375 | \& IN_IMAGE = 1; | |
376 | \& BLOCK_TSB part_0_i_ctx_nonzero_ps0_tsb | |
377 | \& page_size = 8192; | |
378 | \& va_index_bits = 21 : 13; | |
379 | \& tag_addr_bits = 63 : 13; | |
380 | \& data_addr_bits = 39 : 13; | |
381 | \& tag_base = 0x0000000000000044; | |
382 | \& data_base = 0x8000000000000440; | |
383 | \& END BLOCK_TSB | |
384 | \& END BLOCK | |
385 | \& } | |
386 | .Ve | |
387 | .PP | |
388 | Note that until the tool matures, the \fBmidas\fR\-\fBgoldfinger\fR interface | |
389 | may change, so this syntax is deprecated, but it can be useful in a | |
390 | pinch. | |
391 | .Sh "\s-1SECTION\s0 Definitions" | |
392 | .IX Subsection "SECTION Definitions" | |
393 | A \s-1SECTION\s0 defines a region of the diag that may contain up to 3 | |
394 | segments: text, data, and bss. Each of these segments is contiguous | |
395 | in the virtual address space (but not necessarily in the real or | |
396 | physical address spaces). Note that the \fBmidas\fR terminology is | |
397 | different from the \fB\s-1ELF\s0\fR terminology. Each segment in \fBmidas\fR | |
398 | terminology corresponds to an \fB\s-1ELF\s0\fR section. | |
399 | .PP | |
400 | .Vb 1 | |
401 | \& SECTION <name> [section_args] | |
402 | .Ve | |
403 | .PP | |
404 | When a section directive is encountered, all assembly code (and data) | |
405 | that follows is placed in that section, until the next \s-1SECTION\s0 | |
406 | directive is encountered. | |
407 | .PP | |
408 | The \f(CW\*(C`SECTION\*(C'\fR header affects the text and data segments that follow | |
409 | it, until another \f(CW\*(C`SECTION\*(C'\fR header is reached. As a special case, | |
410 | all code and data in the assembly file before the first \f(CW\*(C`SECTION\*(C'\fR | |
411 | header belongs to the first section. A \s-1SECTION\s0 line may be split | |
412 | across multiple lines of input by escaping the newline with a \e. | |
413 | .PP | |
414 | The section_args should define the virtual addresses at which to link | |
415 | the various segments. This is done by a comma-separated list such as: | |
416 | .PP | |
417 | .Vb 2 | |
418 | \& SECTION .MAIN TEXT_VA=0x20000000, DATA_VA=0x60000000, \e | |
419 | \& BSS_VA=0x68030000 | |
420 | .Ve | |
421 | .PP | |
422 | Any of the virtual addresses may be ommitted, but if they are, that | |
423 | segment will not be included in the link. The *_VA symbols are all | |
424 | case\-insensitive. The addresses themselves are assumed to be 64\-bit | |
425 | decimal numbers, unless they start with 0x (in which case they are | |
426 | 64\-bit hex numbers). | |
427 | .PP | |
428 | See the section on \*(L"\s-1ADDRESS\s0 \s-1TRANSLATIONS\s0\*(R" for details on how | |
429 | address translations can be specified for the segments in a section. | |
430 | Note that unless address translations are specified, there is no | |
431 | physical address to place segments in the \fImem.image\fR file! | |
432 | .Sh "\s-1TSB\s0 \s-1OBJECT\s0 \s-1DEFINITIONS\s0" | |
433 | .IX Subsection "TSB OBJECT DEFINITIONS" | |
434 | A \s-1TSB\s0 object is decared with the following syntax: | |
435 | .PP | |
436 | .Vb 1 | |
437 | \& MIDAS_TSB <name> <register> [args] | |
438 | .Ve | |
439 | .PP | |
440 | This defines a \s-1TSB\s0 with the specified name, which is initialized by | |
441 | the config register <register>. It will be instantiated in | |
442 | the memory image if any attr block tries to use it. All \s-1MMU\s0 types get | |
443 | a base address and \s-1TSB\s0 size from the config register as defined in | |
444 | their \s-1PRM\s0. Niagara\-2, in addition, parses a page size (same meaning | |
445 | as the page_size optional argument below) and sun4u/sun4v, which will | |
446 | be used instead of the global default for ttefmt. Note that if you | |
447 | provide the optional arguments page_size and/or ttefmt for Niagara\-2, | |
448 | the optional arguments will override the config register. | |
449 | .PP | |
450 | The optional args can be: | |
451 | .IP "link=<name>" 4 | |
452 | .IX Item "link=<name>" | |
453 | Use the specified name as a link area. This is used in the case of | |
454 | \&\s-1TSB\s0 collisions to hold a linked list. There must be \s-1MIDAS_TSB_LINK\s0 | |
455 | declaration by this name. | |
456 | .IP "force_ctx_zero" 4 | |
457 | .IX Item "force_ctx_zero" | |
458 | If this is specified, then any entries added to this \s-1TSB\s0 will have | |
459 | context bits of zero, regardless of how they are specified in the attr blocks. | |
460 | .IP "page_size=<codedSize>" 4 | |
461 | .IX Item "page_size=<codedSize>" | |
462 | This defines a default page size for all entries that are added to the | |
463 | \&\s-1TSB\s0. This will be used if no TTE_Size_Ptr values are given for the | |
464 | entries. The coded size is the same encoding used in the TTE_Size | |
465 | field. | |
466 | .IP "way=<way>" 4 | |
467 | .IX Item "way=<way>" | |
468 | If a \s-1TSB\s0 is split (which only applies to the \*(L"ultra2\*(R" and \*(L"niagara\*(R" | |
469 | \&\s-1MMU\s0 types), this is specified to midas by creating two TSBs that have | |
470 | the same value of the config register with the split bit set. Midas | |
471 | treats each half of the \s-1TSB\s0 separately. This makes it easy for diags | |
472 | to control which half of the split \s-1TSB\s0 gets each translation. The way | |
473 | definition on the \s-1TSB\s0 line tells midas which half of the split \s-1TSB\s0 | |
474 | applies to this definition. The only legal settings are \*(L"way=0\*(R" and | |
475 | \&\*(L"way=1\*(R". If way is set to zero, the \s-1TSB\s0 is configured just as if it | |
476 | were not split. If way is set to one, then the base address is | |
477 | modifed internally so that it starts after the way=0 \s-1TSB\s0 would end. | |
478 | The way setting is ignored if the \s-1TSB\s0 is not split or if the \s-1MMU\s0 type | |
479 | does not support split TSBs. It is the responsibility of the diag | |
480 | writer to make sure that the two halves of a split \s-1TSB\s0 are configured | |
481 | in a compatible fashion (both sides having split bit on and the same | |
482 | base address). | |
483 | .IP "ttefmt=<format>" 4 | |
484 | .IX Item "ttefmt=<format>" | |
485 | Sets the format for this \s-1TSB\s0 to the specified format (either sun4u or | |
486 | sun4v). This setting will be used instead of the default value of | |
487 | \&\-ttefmt. | |
488 | .Sh "\s-1TSB_LINK\s0 \s-1OBJECT\s0 \s-1DEFINITIONS\s0" | |
489 | .IX Subsection "TSB_LINK OBJECT DEFINITIONS" | |
490 | A \s-1TSB_LINK\s0 object is an area used to store linked lists in the case of | |
491 | collisions in the \s-1TSB\s0. Multiple TSBs can share a \s-1TSB_LINK\s0. The | |
492 | syntax is: | |
493 | .PP | |
494 | .Vb 1 | |
495 | \& MIDAS_TSB_LINK <name> <pa> | |
496 | .Ve | |
497 | .PP | |
498 | This declares a \s-1TSB_LINK\s0 object that will start at the specified \s-1PA\s0. | |
499 | It will be instantiated in the memory image if any \s-1TSB\s0 that uses it is | |
500 | instantiated. | |
501 | .Sh "\s-1ADDRESS\s0 \s-1TRANSLATIONS\s0" | |
502 | .IX Subsection "ADDRESS TRANSLATIONS" | |
503 | Address translations are created by attr_ blocks. The name of the | |
504 | block defines the segment on which the block operates. They syntax is: | |
505 | .PP | |
506 | .Vb 6 | |
507 | \& attr_<segment_name> { | |
508 | \& name|section=<name>, | |
509 | \& <key>=<val>, <key>=<val>, | |
510 | \& <key>=<val> | |
511 | \& ... | |
512 | \& } | |
513 | .Ve | |
514 | .PP | |
515 | The <segment_name> may be \*(L"text\*(R", \*(L"data\*(R", or \*(L"bss\*(R". Each attr | |
516 | block must specify which \s-1SECTION\s0 they belong to. They do this by | |
517 | setting name= or section= inside the block. This means the attr block | |
518 | itself may appear anywhere in the diag, not necessarily lexically | |
519 | inside the section. The blocks are matched to the sections by name, | |
520 | which is case\-insensitive. | |
521 | .PP | |
522 | The contents of the block are a list of key=value pairs (name|section= | |
523 | just being a special case). These pairs can be separated by commas | |
524 | and/or newlines. Key names are case\-insensitive. A \s-1TSB\s0 name may | |
525 | appear as a key with no value. If any other key appears with no | |
526 | =value, the value is assumed to be 1. | |
527 | .PP | |
528 | An example of an attr block is: | |
529 | .PP | |
530 | .Vb 10 | |
531 | \& attr_text { | |
532 | \& Name = .TRAPS, | |
533 | \& RA = 0x120000, | |
534 | \& PA = 0x1000120000, | |
535 | \& part_0_i_ctx_zero_ps0_tsb, | |
536 | \& TTE_Context=0, TTE_V=1, TTE_Size=0, | |
537 | \& TTE_NFO=0, TTE_IE=0, TTE_Soft2=0, TTE_Diag=0, | |
538 | \& TTE_Soft=0, TTE_L=0, TTE_CP=1, TTE_CV=0, | |
539 | \& TTE_E=0, TTE_P=1, TTE_W=1 | |
540 | \& } | |
541 | .Ve | |
542 | .PP | |
543 | An attr block has two purposes: setting up \s-1TSB\s0 mappings and writing to | |
544 | \&\fImem.image\fR. It therefore needs to contain enough information to: | |
545 | .IP "Select a subset of the segment" 4 | |
546 | .IX Item "Select a subset of the segment" | |
547 | An attr block need not define the same translation for an entire | |
548 | segment, and it may define a subset of the segment on which to | |
549 | operated. | |
550 | .IP "Physical address" 4 | |
551 | .IX Item "Physical address" | |
552 | This defines where to write the segment (or segment subset) in the | |
553 | \&\fImem.image\fR. | |
554 | .IP "Define \s-1TSB\s0 parameters" 4 | |
555 | .IX Item "Define TSB parameters" | |
556 | These include a list of TSBs that should contain translations for this | |
557 | section, an \s-1RA\s0 (real address) that should be included in the \s-1TSB\s0, and | |
558 | \&\s-1TTE\s0 elements. The exact details may be processor\-specific. It is | |
559 | controlled by the mmu type. Note that for MMUs that do not have | |
560 | two-level address translation (i.e., \*(L"ultra2\*(R"), there is no \s-1RA\s0, so \s-1PA\s0 | |
561 | is used for TSBs instead. | |
562 | .PP | |
563 | \fISelecting a subset\fR | |
564 | .IX Subsection "Selecting a subset" | |
565 | .PP | |
566 | Selecting a subset consits of defining a starting and stopping virtual | |
567 | address for the block. | |
568 | .PP | |
569 | Defining the starting virtual address | |
570 | .IX Subsection "Defining the starting virtual address" | |
571 | .IP "start_label" 4 | |
572 | .IX Item "start_label" | |
573 | If the key \f(CW\*(C`start_label\*(C'\fR exists it must be a label inside the | |
574 | segment. It is used as the beginning of the attr block. It must be a | |
575 | page-aligned address unless the block is not being entered into a \s-1TSB\s0. | |
576 | .IP "\s-1VA\s0" 4 | |
577 | .IX Item "VA" | |
578 | The attr block may explicitly define a starting virtual address using | |
579 | the tag \f(CW\*(C`VA\*(C'\fR. It is an error if this virtual address is not a | |
580 | page-aligned address within the segment (if the block is not writing a | |
581 | \&\s-1TSB\s0 entry the alignment contraint is relaxed). For this reason, the | |
582 | start_label syntax is the preferred one for most diags. | |
583 | .IP "\fIdefault\fR" 4 | |
584 | .IX Item "default" | |
585 | If neither \s-1VA\s0 nor start_label are specified for an attr block, the | |
586 | starting \s-1VA\s0 for the segment is used. | |
587 | .PP | |
588 | Defining the ending virtual address | |
589 | .IX Subsection "Defining the ending virtual address" | |
590 | .PP | |
591 | There are three ways to define the ending address for an attr block. | |
592 | .IP "end_label" 4 | |
593 | .IX Item "end_label" | |
594 | If \f(CW\*(C`end_label\*(C'\fR is defined, it must be label inside the segment (and | |
595 | of course, it must appear after the starting \s-1VA\s0). The \f(CW\*(C`attr_text\*(C'\fR | |
596 | definiton ends at the address of the label. The address need not be | |
597 | page\-aligned. | |
598 | .IP "end_va" 4 | |
599 | .IX Item "end_va" | |
600 | The attr block may explicitly define an ending virtual address. It is | |
601 | an error if this address is not part of this segment. If the special | |
602 | attribute \f(CW\*(C`uninitialized\*(C'\fR is used (see below), then end_va may be | |
603 | specified past the end of the segment. The \f(CW\*(C`uninitialized\*(C'\fR attribute | |
604 | implies \f(CW\*(C`tsbonly\*(C'\fR (i.e., data is written to the \s-1TSB\s0 but not to the | |
605 | memory image). | |
606 | .IP "\fIdefault\fR" 4 | |
607 | .IX Item "default" | |
608 | If neither end_label nor end_va are specified, then the attr block | |
609 | lasts until the end of the section. | |
610 | .PP | |
611 | \fIPhysical address\fR | |
612 | .IX Subsection "Physical address" | |
613 | .PP | |
614 | An attr block must have one of the following keys to define the | |
615 | physical address. The physical address is used to write \fImem.image\fR | |
616 | .IP "\s-1PA\s0" 4 | |
617 | .IX Item "PA" | |
618 | The physical address is specified with the tag \*(L"\s-1PA\s0\*(R". It should be set | |
619 | to an address, and the subset of the segment will be written to the | |
620 | \&\fImem.image\fR file at that physical address. It is an error to write | |
621 | to the same physical address twice in the same diag. | |
622 | .IP "tsbonly" 4 | |
623 | .IX Item "tsbonly" | |
624 | This special key tells the attr block not to write anything to | |
625 | \&\fImem.image\fR. It can be used if you want to create \s-1TSB\s0 entries but do | |
626 | not want to overwrite something to \fImem.image\fR. If the key \*(L"\s-1PA\s0\*(R" is | |
627 | included, it is used only for symbol table generation. | |
628 | .IP "uninitialized" 4 | |
629 | .IX Item "uninitialized" | |
630 | This is exactly the same as tsbonly, except that normally the \*(L"end_va\*(R" | |
631 | key is checked to make sure that it is contained in the segment. | |
632 | Using uninitialized instead of tsbonly suspends that check. | |
633 | .ie n .IP "hypervisor (or bypass on ""ultra2"" \s-1MMU\s0)" 4 | |
634 | .el .IP "hypervisor (or bypass on ``ultra2'' \s-1MMU\s0)" 4 | |
635 | .IX Item "hypervisor (or bypass on ultra2 MMU)" | |
636 | The special tag \*(L"hypervisor\*(R" tells the attr block bypass both \s-1VA\s0 to \s-1RA\s0 | |
637 | translation and \s-1RA\s0 to \s-1PA\s0 tranlation. The segment will be completely | |
638 | unmapped. Therefore, it will not generate any \s-1TSB\s0 mappings, and it | |
639 | will write to \fImem.image\fR at PA=VA (actually, it generates a \s-1PA\s0 from | |
640 | as many low bits of the \s-1VA\s0 as will fit in a \s-1PA\s0). It is used for | |
641 | segments where the \s-1MMU\s0 is off. For mmus that have only one level of | |
642 | address translation (i.e., \*(L"ultra2\*(R"), the key \*(L"hypervisor\*(R" does not | |
643 | exist, but \*(L"bypass\*(R" has the same meaning. | |
644 | .IP "compressimage" 4 | |
645 | .IX Item "compressimage" | |
646 | This does not control the address, but it does affect how \fImem.image\fR | |
647 | creation is done. If compressimage is given in an attr block then | |
648 | lines of zeros are suppressed in \fImem.image\fR generation. Each | |
649 | aligned 32\-byte chunk is compared against 0. If all bits are 0, then | |
650 | it is not written to mem.image. If the global \-env_zero switch is | |
651 | enabled (on by default in Niagara\-1), then a backdoor mechanism is | |
652 | used to initialize the memory to zero in the environment. Otherwise, | |
653 | it is left uninitialized. If the environment does not intialize all | |
654 | memory to zero, then this can actually change the meaning of | |
655 | mem.image, since it makes zero-ed memory uninitialized, rather than | |
656 | intialized to zero. If the flag \-nocompress_image is given to | |
657 | \&\fBmidas\fR, then no blocks are compressed, regardless of compressimage | |
658 | tags. | |
659 | .Sp | |
660 | \fI\s-1TSB\s0 parameters\fR | |
661 | .IX Subsection "TSB parameters" | |
662 | .Sp | |
663 | The following parameters should be set in each attr block (unless it | |
664 | contains the \*(L"hypervisor\*(R" key described above, or the \*(L"bypass\*(R" key for | |
665 | \&\*(L"ultra2\*(R"): | |
666 | .RS 4 | |
667 | .IP "\s-1RA\s0" 4 | |
668 | .IX Item "RA" | |
669 | This defines the real address (middle of the 3\-address scheme). It is | |
670 | the address to be written to the \s-1TSB\s0 data. It must be page\-aligned. | |
671 | In the \*(L"ultra2\*(R" \s-1MMU\s0, there is no \s-1RA\s0, so the \s-1PA\s0 gets double\-duty: \s-1PA\s0 is | |
672 | used both for mem.image generation and for \s-1TSB\s0 data. | |
673 | .IP "bypass" 4 | |
674 | .IX Item "bypass" | |
675 | This directive means to bypass \s-1VA\s0 to \s-1RA\s0 translation. In an \s-1MMU\s0 with | |
676 | two levels of address translation (like niagara), it simply sets RA=VA | |
677 | (actually, as many low bits of \s-1VA\s0 as will fit). It is an error to | |
678 | specify both \s-1RA\s0 and bypass. In an \s-1MMU\s0 with one level of translation | |
679 | (\*(L"ultra2\*(R"), it means to bypass all address translation, so its | |
680 | function is similar to the hypervisor directive described above. | |
681 | .IP "<tsb_name>" 4 | |
682 | .IX Item "<tsb_name>" | |
683 | Any tsb names that are listed (and there may be more than one) will | |
684 | cause the attr block to add the subset to those TSBs. The tsb_names | |
685 | must be defined somewhere in the diag with a \s-1MIDAS_TSB\s0 directive. | |
686 | .IP "notsb" 4 | |
687 | .IX Item "notsb" | |
688 | Tells the attr block not to do any \s-1TSB\s0 generation. If \s-1RA\s0 is provided, | |
689 | it is simply used in the symbol table. | |
690 | .RE | |
691 | .RS 4 | |
692 | .Sp | |
693 | Unless notsb is defined or the section is completely unmapped (bypass | |
694 | for \*(L"ultra2\*(R" or hypervisor for other MMUs), the attr block will be | |
695 | writing \s-1TSB\s0 entries. The following parameters are used to set the | |
696 | appropriate bits of the \s-1TSB\s0 entry. How exactly the \s-1TSB\s0 entries are | |
697 | formed is mmu\-specific. Check the \s-1PRM\s0 for your processor. The | |
698 | default value for \s-1TTE_V\s0 (valid) is 1. The default value for all other | |
699 | fields is 0. | |
700 | .Sp | |
701 | \fIMMU-Specific \s-1TTE\s0 Settings\fR | |
702 | .IX Subsection "MMU-Specific TTE Settings" | |
703 | .Sp | |
704 | The fields in the \s-1TSB\s0 tag and data depend on the \s-1MMU\s0 type and the | |
705 | currently configured ttefmt setting (sun4u or sun4v). The ttefmt is | |
706 | can be contralled by the TSBs (which is always the case in Niagara\-2) | |
707 | or by the global default set by \-ttefmt. The \s-1MMU\s0 specific settings | |
708 | are described below. The default for each \s-1TTE\s0 setting is 0, except | |
709 | for \s-1TTE_V\s0 (valid), which defaults to 1. All \s-1TTE\s0 tags are | |
710 | case\-insensitive. | |
711 | .Sp | |
712 | Ultrasparc \s-1II\s0 \s-1MMU\s0 \*(L"ultra2\*(R" | |
713 | .IX Subsection "Ultrasparc II MMU ultra2" | |
714 | .Sp | |
715 | The ultra2 \s-1MMU\s0 type supports only the sun4u \s-1TTE\s0 data format. | |
716 | .IP "\s-1TTE_G\s0 Tag: 1 bit Global" 4 | |
717 | .IX Item "TTE_G Tag: 1 bit Global" | |
718 | .PD 0 | |
719 | .IP "TTE_Context Tag:13 bits Context" 4 | |
720 | .IX Item "TTE_Context Tag:13 bits Context" | |
721 | .PD | |
722 | %%TTE \s-1DATA\s0 ultra2 sun4u | |
723 | .RE | |
724 | .RS 4 | |
725 | .Sp | |
726 | Niagara \s-1MMU\s0 \*(L"niagara\*(R" | |
727 | .IX Subsection "Niagara MMU niagara" | |
728 | .Sp | |
729 | The niagara \s-1MMU\s0 supports both the sun4u and sun4v \s-1TTE\s0 data formats. | |
730 | .Sp | |
731 | For sun4u, the following fields are valid: | |
732 | .IP "TTE_Context Tag:13 bits Context" 4 | |
733 | .IX Item "TTE_Context Tag:13 bits Context" | |
734 | %%TTE \s-1DATA\s0 niagara sun4u | |
735 | .RE | |
736 | .RS 4 | |
737 | .Sp | |
738 | The following fields are valid for sun4v: | |
739 | .IP "TTE_Context Tag:13 bits Context" 4 | |
740 | .IX Item "TTE_Context Tag:13 bits Context" | |
741 | %%TTE \s-1DATA\s0 niagara sun4v | |
742 | .RE | |
743 | .RS 4 | |
744 | .Sp | |
745 | Niagara2 \s-1MMU\s0 \*(L"niagara2\*(R" | |
746 | .IX Subsection "Niagara2 MMU niagara2" | |
747 | .Sp | |
748 | The niagara2 \s-1MMU\s0 supports both the sun4u and sun4v \s-1TTE\s0 data format. | |
749 | .Sp | |
750 | For sun4u, the following fields are valid: | |
751 | .IP "TTE_Context Tag:13 bits Context" 4 | |
752 | .IX Item "TTE_Context Tag:13 bits Context" | |
753 | %%TTE \s-1DATA\s0 niagara2 sun4u | |
754 | .RE | |
755 | .RS 4 | |
756 | .Sp | |
757 | The following fields are valid for sun4v: | |
758 | .IP "TTE_Context Tag:13 bits Context" 4 | |
759 | .IX Item "TTE_Context Tag:13 bits Context" | |
760 | %%TTE \s-1DATA\s0 niagara2 sun4v | |
761 | .RE | |
762 | .RS 4 | |
763 | .IP "TTE_Context Tag:13 bits Context" 4 | |
764 | .IX Item "TTE_Context Tag:13 bits Context" | |
765 | %%TTE \s-1DATA\s0 sun4v | |
766 | .RE | |
767 | .RS 4 | |
768 | .Sp | |
769 | There are a few special cases to be aware of: | |
770 | .IP "TTE_Size" 4 | |
771 | .IX Item "TTE_Size" | |
772 | This is the size bits field to use in the \s-1TSB\s0 entry. It is also used | |
773 | to calculate the number of pages the attr block will create. The attr | |
774 | block will create as many pages as it needs to to span the section. | |
775 | The TTE_Size field controls the size of these pages. See the \s-1PRM\s0 for | |
776 | the exact coding of page size in TTE_Size. For Niagara, Niagara\-2, | |
777 | the encoding is: | |
778 | .RS 4 | |
779 | .IP "0 \-> 8 kB" 4 | |
780 | .IX Item "0 -> 8 kB" | |
781 | .PD 0 | |
782 | .IP "1 \-> 64 kB" 4 | |
783 | .IX Item "1 -> 64 kB" | |
784 | .IP "2 \-> 512 kB (illegal on Niagara and Niagara\-2)" 4 | |
785 | .IX Item "2 -> 512 kB (illegal on Niagara and Niagara-2)" | |
786 | .IP "3 \-> 4 \s-1MB\s0" 4 | |
787 | .IX Item "3 -> 4 MB" | |
788 | .IP "5 \-> 256 \s-1MB\s0" 4 | |
789 | .IX Item "5 -> 256 MB" | |
790 | .IP "6 \-> 2 \s-1GB\s0 (illegal on Niagara and Niagara\-2)" 4 | |
791 | .IX Item "6 -> 2 GB (illegal on Niagara and Niagara-2)" | |
792 | .IP "7 \-> 16 \s-1GB\s0 (illegal on Niagara and Niagara\-2)" 4 | |
793 | .IX Item "7 -> 16 GB (illegal on Niagara and Niagara-2)" | |
794 | .RE | |
795 | .RS 4 | |
796 | .PD | |
797 | .Sp | |
798 | The \*(L"ultra2\*(R" \s-1MMU\s0 only has a 2\-bit size field, so it supports page | |
799 | sizes 0\-3 (which are also 8 kB \- 4 \s-1MB\s0). | |
800 | .Sp | |
801 | Note that when the above sections state that \s-1VA\s0, \s-1RA\s0, and \s-1PA\s0 must be | |
802 | page-aligned when adding them to a \s-1TSB\s0, this is where the page size | |
803 | comes from. | |
804 | .RE | |
805 | .IP "TTE_Size_Ptr" 4 | |
806 | .IX Item "TTE_Size_Ptr" | |
807 | The page size is used in the formula to calculate a \s-1TSB\s0 pointer. The | |
808 | page size used for pointer calculation is controlled by a hardware | |
809 | register, but \fBmidas\fR needs to set up the TSBs statically. By | |
810 | default, the attr block with use TTE_Size when it computes the \s-1TSB\s0 | |
811 | index (or the \s-1TSB\s0 page_size parameter/Niagara\-2 \s-1TSB\s0 config, if one is | |
812 | defined), as well as for the uses above. If you set TTE_Size_Ptr, | |
813 | however, it will use this as the page size setting when computing the | |
814 | \&\s-1TSB\s0 index. Use this whenever you wish to have a different setting for | |
815 | TTE_Size than the hardware will have in its config register. | |
816 | .RE | |
817 | .RS 4 | |
818 | .Sh "High Level Languages" | |
819 | .IX Subsection "High Level Languages" | |
820 | The output of compilers of high-level languages may be inserted into midas. | |
821 | .Sp | |
822 | \fIObject files\fR | |
823 | .IX Subsection "Object files" | |
824 | .Sp | |
825 | The midas directive: | |
826 | .Sp | |
827 | .Vb 1 | |
828 | \& MIDAS_OBJ FILE=<something.o> | |
829 | .Ve | |
830 | .Sp | |
831 | may be placed inside any section. That object file will be linked | |
832 | with the assembly output for the section and will share its attr | |
833 | blocks. No special interpretation is done on the contents of the | |
834 | object file \- the text, data, and bss segments are simply linked in | |
835 | with the output of the assembler for that section. The search path | |
836 | for .o files is controlled by the \-L switch. The default path is the | |
837 | starting directory, and <diag_root>/verif/diag. | |
838 | .Sp | |
839 | \fILibrary files\fR | |
840 | .IX Subsection "Library files" | |
841 | .Sp | |
842 | The midas directive: | |
843 | .Sp | |
844 | .Vb 1 | |
845 | \& MIDAS_LIB FILE=<something.a> | |
846 | .Ve | |
847 | .Sp | |
848 | Works just like a \s-1MIDAS_OBJ\s0 directive, except that it includes a | |
849 | library in the link. Note that the library must be static (i.e., a .a | |
850 | file, and not a .so file), because there is no runtime linker in the | |
851 | diag environment. Other than the file format, the difference between | |
852 | a library file and an object file, is that an object file will include | |
853 | all text/data/bss from the file, but linking with a library file will | |
854 | cause only those symbols that are actually used to be included. | |
855 | .Sp | |
856 | Library files will also search the same link path as object files. | |
857 | .Sp | |
858 | \fIC files\fR | |
859 | .IX Subsection "C files" | |
860 | .Sp | |
861 | Simiar to object files, C language files may be included with the | |
862 | directive: | |
863 | .Sp | |
864 | .Vb 1 | |
865 | \& MIDAS_CC FILE=<something.c> [OUTPUT=<something.o>] [ARGS=-O2] | |
866 | .Ve | |
867 | .Sp | |
868 | The \s-1OUTPUT\s0 and \s-1ARGS\s0 tags are optional, but the \s-1FILE\s0 tag is mandatory. | |
869 | The search path for the C source file is controleld by the \-C switch, | |
870 | and the default is the starting directory, then | |
871 | <diag_root>/verif/diag/c. The \s-1ARGS\s0 tag (which must appear | |
872 | last, since the args last until the end of the line) is arguments to | |
873 | gcc. You must not use the \-o or \-c switches, since midas will provide | |
874 | its own. If \*(L"\-S\*(R" is supplied to gcc through the \s-1ARGS\s0 tag, then gcc \-S | |
875 | will be used to create an assembly file in the Sectioning phase, which | |
876 | will then be assembled like all the other assembly files in the | |
877 | Assembly phase. If \-S is not present, then nothing is done in the | |
878 | Sectioning phase (except for finding the C file and copying it to the | |
879 | build directory). Rather, gcc is used to compile the C file directly | |
880 | to an object file during the assembly phase. The object file, | |
881 | generated either by gcc or by the of assembling of gcc \-S, is then | |
882 | linked in with the rest of the section. Once the object file is | |
883 | generated, it is treated just as a \s-1MIDAS_OBJ\s0 directive. | |
884 | .Sp | |
885 | Stack | |
886 | .IX Subsection "Stack" | |
887 | .Sp | |
888 | Compiled C code expects the system to set up a stack for it before it | |
889 | runs. Template files are provided for this purpose. Be sure to use | |
890 | them or have some solution for setting up the stack if you are working | |
891 | with compiled code. | |
892 | .SH "AUTHOR" | |
893 | .IX Header "AUTHOR" | |
894 | .SH "SEE ALSO" | |
895 | .IX Header "SEE ALSO" | |
896 | \&\fBmidas\fR(1), tre_perldoc Midas, \fBpal\fR(1), \fBgoldfinger\fR(1). |