"Fossies" - the Fresh Open Source Software Archive

Member "nasm-2.15.05/doc/html/nasmdo10.html" (28 Aug 2020, 23739 Bytes) of package /linux/misc/nasm-2.15.05-xdoc.tar.xz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
    2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
    3 <html xmlns="http://www.w3.org/1999/xhtml">
    4 <head>
    5 <title>NASM - The Netwide Assembler</title>
    6 <link href="nasmdoc.css" rel="stylesheet" type="text/css" />
    7 <link href="local.css" rel="stylesheet" type="text/css" />
    8 </head>
    9 <body>
   10 <ul class="navbar">
   11 <li class="first"><a class="prev" href="nasmdoc9.html">Chapter 9</a></li>
   12 <li><a class="next" href="nasmdo11.html">Chapter 11</a></li>
   13 <li><a class="toc" href="nasmdoc0.html">Contents</a></li>
   14 <li class="last"><a class="index" href="nasmdoci.html">Index</a></li>
   15 </ul>
   16 <div class="title">
   17 <h1>NASM - The Netwide Assembler</h1>
   18 <span class="subtitle">version 2.15.05</span>
   19 </div>
   20 <div class="contents"
   21 >
   22 <h2 id="chapter-10">Chapter 10: Writing 32-bit Code (Unix, Win32, DJGPP)</h2>
   23 <p>This chapter attempts to cover some of the common issues involved when
   24 writing 32-bit code, to run under Win32 or Unix, or to be linked with C
   25 code generated by a Unix-style C compiler such as DJGPP. It covers how to
   26 write assembly code to interface with 32-bit C routines, and how to write
   27 position-independent code for shared libraries.</p>
   28 <p>Almost all 32-bit code, and in particular all code running under
   29 <code>Win32</code>, <code>DJGPP</code> or any of the PC Unix variants, runs
   30 in <em>flat</em> memory model. This means that the segment registers and
   31 paging have already been set up to give you the same 32-bit 4Gb address
   32 space no matter what segment you work relative to, and that you should
   33 ignore all segment registers completely. When writing flat-model
   34 application code, you never need to use a segment override or modify any
   35 segment register, and the code-section addresses you pass to
   36 <code>CALL</code> and <code>JMP</code> live in the same address space as
   37 the data-section addresses you access your variables by and the
   38 stack-section addresses you access local variables and procedure parameters
   39 by. Every address is 32 bits long and contains only an offset part.</p>
   40 <h3 id="section-10.1">10.1 Interfacing to 32-bit C Programs</h3>
   41 <p>A lot of the discussion in <a href="nasmdoc9.html#section-9.4">section
   42 9.4</a>, about interfacing to 16-bit C programs, still applies when working
   43 in 32 bits. The absence of memory models or segmentation worries simplifies
   44 things a lot.</p>
   45 <h4 id="section-10.1.1">10.1.1 External Symbol Names</h4>
   46 <p>Most 32-bit C compilers share the convention used by 16-bit compilers,
   47 that the names of all global symbols (functions or data) they define are
   48 formed by prefixing an underscore to the name as it appears in the C
   49 program. However, not all of them do: the <code>ELF</code> specification
   50 states that C symbols do <em>not</em> have a leading underscore on their
   51 assembly-language names.</p>
   52 <p>The older Linux <code>a.out</code> C compiler, all <code>Win32</code>
   53 compilers, <code>DJGPP</code>, and <code>NetBSD</code> and
   54 <code>FreeBSD</code>, all use the leading underscore; for these compilers,
   55 the macros <code>cextern</code> and <code>cglobal</code>, as given in
   56 <a href="nasmdoc9.html#section-9.4.1">section 9.4.1</a>, will still work.
   57 For <code>ELF</code>, though, the leading underscore should not be used.</p>
   58 <p>See also <a href="nasmdoc2.html#section-2.1.28">section 2.1.28</a>.</p>
   59 <h4 id="section-10.1.2">10.1.2 Function Definitions and Function Calls</h4>
   60 <p>The C calling convention in 32-bit programs is as follows. In the
   61 following description, the words <em>caller</em> and <em>callee</em> are
   62 used to denote the function doing the calling and the function which gets
   63 called.</p>
   64 <ul>
   65 <li>
   66 <p>The caller pushes the function's parameters on the stack, one after
   67 another, in reverse order (right to left, so that the first argument
   68 specified to the function is pushed last).</p>
   69 </li>
   70 <li>
   71 <p>The caller then executes a near <code>CALL</code> instruction to pass
   72 control to the callee.</p>
   73 </li>
   74 <li>
   75 <p>The callee receives control, and typically (although this is not
   76 actually necessary, in functions which do not need to access their
   77 parameters) starts by saving the value of <code>ESP</code> in
   78 <code>EBP</code> so as to be able to use <code>EBP</code> as a base pointer
   79 to find its parameters on the stack. However, the caller was probably doing
   80 this too, so part of the calling convention states that <code>EBP</code>
   81 must be preserved by any C function. Hence the callee, if it is going to
   82 set up <code>EBP</code> as a frame pointer, must push the previous value
   83 first.</p>
   84 </li>
   85 <li>
   86 <p>The callee may then access its parameters relative to <code>EBP</code>.
   87 The doubleword at <code>[EBP]</code> holds the previous value of
   88 <code>EBP</code> as it was pushed; the next doubleword, at
   89 <code>[EBP+4]</code>, holds the return address, pushed implicitly by
   90 <code>CALL</code>. The parameters start after that, at
   91 <code>[EBP+8]</code>. The leftmost parameter of the function, since it was
   92 pushed last, is accessible at this offset from <code>EBP</code>; the others
   93 follow, at successively greater offsets. Thus, in a function such as
   94 <code>printf</code> which takes a variable number of parameters, the
   95 pushing of the parameters in reverse order means that the function knows
   96 where to find its first parameter, which tells it the number and type of
   97 the remaining ones.</p>
   98 </li>
   99 <li>
  100 <p>The callee may also wish to decrease <code>ESP</code> further, so as to
  101 allocate space on the stack for local variables, which will then be
  102 accessible at negative offsets from <code>EBP</code>.</p>
  103 </li>
  104 <li>
  105 <p>The callee, if it wishes to return a value to the caller, should leave
  106 the value in <code>AL</code>, <code>AX</code> or <code>EAX</code> depending
  107 on the size of the value. Floating-point results are typically returned in
  108 <code>ST0</code>.</p>
  109 </li>
  110 <li>
  111 <p>Once the callee has finished processing, it restores <code>ESP</code>
  112 from <code>EBP</code> if it had allocated local stack space, then pops the
  113 previous value of <code>EBP</code>, and returns via <code>RET</code>
  114 (equivalently, <code>RETN</code>).</p>
  115 </li>
  116 <li>
  117 <p>When the caller regains control from the callee, the function parameters
  118 are still on the stack, so it typically adds an immediate constant to
  119 <code>ESP</code> to remove them (instead of executing a number of slow
  120 <code>POP</code> instructions). Thus, if a function is accidentally called
  121 with the wrong number of parameters due to a prototype mismatch, the stack
  122 will still be returned to a sensible state since the caller, which
  123 <em>knows</em> how many parameters it pushed, does the removing.</p>
  124 </li>
  125 </ul>
  126 <p>There is an alternative calling convention used by Win32 programs for
  127 Windows API calls, and also for functions called <em>by</em> the Windows
  128 API such as window procedures: they follow what Microsoft calls the
  129 <code>__stdcall</code> convention. This is slightly closer to the Pascal
  130 convention, in that the callee clears the stack by passing a parameter to
  131 the <code>RET</code> instruction. However, the parameters are still pushed
  132 in right-to-left order.</p>
  133 <p>Thus, you would define a function in C style in the following way:</p>
  134 <pre>
  135 global  _myfunc 
  136 
  137 _myfunc: 
  138         push    ebp 
  139         mov     ebp,esp 
  140         sub     esp,0x40        ; 64 bytes of local stack space 
  141         mov     ebx,[ebp+8]     ; first parameter to function 
  142 
  143         ; some more code 
  144 
  145         leave                   ; mov esp,ebp / pop ebp 
  146         ret
  147 </pre>
  148 <p>At the other end of the process, to call a C function from your assembly
  149 code, you would do something like this:</p>
  150 <pre>
  151 extern  _printf 
  152 
  153         ; and then, further down... 
  154 
  155         push    dword [myint]   ; one of my integer variables 
  156         push    dword mystring  ; pointer into my data segment 
  157         call    _printf 
  158         add     esp,byte 8      ; `byte' saves space 
  159 
  160         ; then those data items... 
  161 
  162 segment _DATA 
  163 
  164 myint       dd   1234 
  165 mystring    db   'This number -&gt; %d &lt;- should be 1234',10,0
  166 </pre>
  167 <p>This piece of code is the assembly equivalent of the C code</p>
  168 <pre>
  169     int myint = 1234; 
  170     printf("This number -&gt; %d &lt;- should be 1234\n", myint);
  171 </pre>
  172 <h4 id="section-10.1.3">10.1.3 Accessing Data Items</h4>
  173 <p>To get at the contents of C variables, or to declare variables which C
  174 can access, you need only declare the names as <code>GLOBAL</code> or
  175 <code>EXTERN</code>. (Again, the names require leading underscores, as
  176 stated in <a href="#section-10.1.1">section 10.1.1</a>.) Thus, a C variable
  177 declared as <code>int i</code> can be accessed from assembler as</p>
  178 <pre>
  179           extern _i 
  180           mov eax,[_i]
  181 </pre>
  182 <p>And to declare your own integer variable which C programs can access as
  183 <code>extern int j</code>, you do this (making sure you are assembling in
  184 the <code>_DATA</code> segment, if necessary):</p>
  185 <pre>
  186           global _j 
  187 _j        dd 0
  188 </pre>
  189 <p>To access a C array, you need to know the size of the components of the
  190 array. For example, <code>int</code> variables are four bytes long, so if a
  191 C program declares an array as <code>int a[10]</code>, you can access
  192 <code>a[3]</code> by coding <code>mov ax,[_a+12]</code>. (The byte offset
  193 12 is obtained by multiplying the desired array index, 3, by the size of
  194 the array element, 4.) The sizes of the C base types in 32-bit compilers
  195 are: 1 for <code>char</code>, 2 for <code>short</code>, 4 for
  196 <code>int</code>, <code>long</code> and <code>float</code>, and 8 for
  197 <code>double</code>. Pointers, being 32-bit addresses, are also 4 bytes
  198 long.</p>
  199 <p>To access a C data structure, you need to know the offset from the base
  200 of the structure to the field you are interested in. You can either do this
  201 by converting the C structure definition into a NASM structure definition
  202 (using <code>STRUC</code>), or by calculating the one offset and using just
  203 that.</p>
  204 <p>To do either of these, you should read your C compiler's manual to find
  205 out how it organizes data structures. NASM gives no special alignment to
  206 structure members in its own <code>STRUC</code> macro, so you have to
  207 specify alignment yourself if the C compiler generates it. Typically, you
  208 might find that a structure like</p>
  209 <pre>
  210 struct { 
  211     char c; 
  212     int i; 
  213 } foo;
  214 </pre>
  215 <p>might be eight bytes long rather than five, since the <code>int</code>
  216 field would be aligned to a four-byte boundary. However, this sort of
  217 feature is sometimes a configurable option in the C compiler, either using
  218 command-line options or <code>#pragma</code> lines, so you have to find out
  219 how your own compiler does it.</p>
  220 <h4 id="section-10.1.4">10.1.4 <code>c32.mac</code>: Helper Macros for the 32-bit C Interface</h4>
  221 <p>Included in the NASM archives, in the <code>misc</code> directory, is a
  222 file <code>c32.mac</code> of macros. It defines three macros:
  223 <code>proc</code>, <code>arg</code> and <code>endproc</code>. These are
  224 intended to be used for C-style procedure definitions, and they automate a
  225 lot of the work involved in keeping track of the calling convention.</p>
  226 <p>An example of an assembly function using the macro set is given here:</p>
  227 <pre>
  228 proc    _proc32 
  229 
  230 %$i     arg 
  231 %$j     arg 
  232         mov     eax,[ebp + %$i] 
  233         mov     ebx,[ebp + %$j] 
  234         add     eax,[ebx] 
  235 
  236 endproc
  237 </pre>
  238 <p>This defines <code>_proc32</code> to be a procedure taking two
  239 arguments, the first (<code>i</code>) an integer and the second
  240 (<code>j</code>) a pointer to an integer. It returns <code>i + *j</code>.</p>
  241 <p>Note that the <code>arg</code> macro has an <code>EQU</code> as the
  242 first line of its expansion, and since the label before the macro call gets
  243 prepended to the first line of the expanded macro, the <code>EQU</code>
  244 works, defining <code>%$i</code> to be an offset from <code>BP</code>. A
  245 context-local variable is used, local to the context pushed by the
  246 <code>proc</code> macro and popped by the <code>endproc</code> macro, so
  247 that the same argument name can be used in later procedures. Of course, you
  248 don't <em>have</em> to do that.</p>
  249 <p><code>arg</code> can take an optional parameter, giving the size of the
  250 argument. If no size is given, 4 is assumed, since it is likely that many
  251 function parameters will be of type <code>int</code> or pointers.</p>
  252 <h3 id="section-10.2">10.2 Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries</h3>
  253 <p><code>ELF</code> replaced the older <code>a.out</code> object file
  254 format under Linux because it contains support for position-independent
  255 code (PIC), which makes writing shared libraries much easier. NASM supports
  256 the <code>ELF</code> position-independent code features, so you can write
  257 Linux <code>ELF</code> shared libraries in NASM.</p>
  258 <p>NetBSD, and its close cousins FreeBSD and OpenBSD, take a different
  259 approach by hacking PIC support into the <code>a.out</code> format. NASM
  260 supports this as the <code>aoutb</code> output format, so you can write BSD
  261 shared libraries in NASM too.</p>
  262 <p>The operating system loads a PIC shared library by memory-mapping the
  263 library file at an arbitrarily chosen point in the address space of the
  264 running process. The contents of the library's code section must therefore
  265 not depend on where it is loaded in memory.</p>
  266 <p>Therefore, you cannot get at your variables by writing code like this:</p>
  267 <pre>
  268         mov     eax,[myvar]             ; WRONG
  269 </pre>
  270 <p>Instead, the linker provides an area of memory called the <em>global
  271 offset table</em>, or GOT; the GOT is situated at a constant distance from
  272 your library's code, so if you can find out where your library is loaded
  273 (which is typically done using a <code>CALL</code> and <code>POP</code>
  274 combination), you can obtain the address of the GOT, and you can then load
  275 the addresses of your variables out of linker-generated entries in the GOT.</p>
  276 <p>The <em>data</em> section of a PIC shared library does not have these
  277 restrictions: since the data section is writable, it has to be copied into
  278 memory anyway rather than just paged in from the library file, so as long
  279 as it's being copied it can be relocated too. So you can put ordinary types
  280 of relocation in the data section without too much worry (but see
  281 <a href="#section-10.2.4">section 10.2.4</a> for a caveat).</p>
  282 <h4 id="section-10.2.1">10.2.1 Obtaining the Address of the GOT</h4>
  283 <p>Each code module in your shared library should define the GOT as an
  284 external symbol:</p>
  285 <pre>
  286 extern  _GLOBAL_OFFSET_TABLE_   ; in ELF 
  287 extern  __GLOBAL_OFFSET_TABLE_  ; in BSD a.out
  288 </pre>
  289 <p>At the beginning of any function in your shared library which plans to
  290 access your data or BSS sections, you must first calculate the address of
  291 the GOT. This is typically done by writing the function in this form:</p>
  292 <pre>
  293 func:   push    ebp 
  294         mov     ebp,esp 
  295         push    ebx 
  296         call    .get_GOT 
  297 .get_GOT: 
  298         pop     ebx 
  299         add     ebx,_GLOBAL_OFFSET_TABLE_+$$-.get_GOT wrt ..gotpc 
  300 
  301         ; the function body comes here 
  302 
  303         mov     ebx,[ebp-4] 
  304         mov     esp,ebp 
  305         pop     ebp 
  306         ret
  307 </pre>
  308 <p>(For BSD, again, the symbol <code>_GLOBAL_OFFSET_TABLE</code> requires a
  309 second leading underscore.)</p>
  310 <p>The first two lines of this function are simply the standard C prologue
  311 to set up a stack frame, and the last three lines are standard C function
  312 epilogue. The third line, and the fourth to last line, save and restore the
  313 <code>EBX</code> register, because PIC shared libraries use this register
  314 to store the address of the GOT.</p>
  315 <p>The interesting bit is the <code>CALL</code> instruction and the
  316 following two lines. The <code>CALL</code> and <code>POP</code> combination
  317 obtains the address of the label <code>.get_GOT</code>, without having to
  318 know in advance where the program was loaded (since the <code>CALL</code>
  319 instruction is encoded relative to the current position). The
  320 <code>ADD</code> instruction makes use of one of the special PIC relocation
  321 types: GOTPC relocation. With the <code>WRT ..gotpc</code> qualifier
  322 specified, the symbol referenced (here <code>_GLOBAL_OFFSET_TABLE_</code>,
  323 the special symbol assigned to the GOT) is given as an offset from the
  324 beginning of the section. (Actually, <code>ELF</code> encodes it as the
  325 offset from the operand field of the <code>ADD</code> instruction, but NASM
  326 simplifies this deliberately, so you do things the same way for both
  327 <code>ELF</code> and <code>BSD</code>.) So the instruction then
  328 <em>adds</em> the beginning of the section, to get the real address of the
  329 GOT, and subtracts the value of <code>.get_GOT</code> which it knows is in
  330 <code>EBX</code>. Therefore, by the time that instruction has finished,
  331 <code>EBX</code> contains the address of the GOT.</p>
  332 <p>If you didn't follow that, don't worry: it's never necessary to obtain
  333 the address of the GOT by any other means, so you can put those three
  334 instructions into a macro and safely ignore them:</p>
  335 <pre>
  336 %macro  get_GOT 0 
  337 
  338         call    %%getgot 
  339   %%getgot: 
  340         pop     ebx 
  341         add     ebx,_GLOBAL_OFFSET_TABLE_+$$-%%getgot wrt ..gotpc 
  342 
  343 %endmacro
  344 </pre>
  345 <h4 id="section-10.2.2">10.2.2 Finding Your Local Data Items</h4>
  346 <p>Having got the GOT, you can then use it to obtain the addresses of your
  347 data items. Most variables will reside in the sections you have declared;
  348 they can be accessed using the <code>..gotoff</code> special
  349 <code>WRT</code> type. The way this works is like this:</p>
  350 <pre>
  351         lea     eax,[ebx+myvar wrt ..gotoff]
  352 </pre>
  353 <p>The expression <code>myvar wrt ..gotoff</code> is calculated, when the
  354 shared library is linked, to be the offset to the local variable
  355 <code>myvar</code> from the beginning of the GOT. Therefore, adding it to
  356 <code>EBX</code> as above will place the real address of <code>myvar</code>
  357 in <code>EAX</code>.</p>
  358 <p>If you declare variables as <code>GLOBAL</code> without specifying a
  359 size for them, they are shared between code modules in the library, but do
  360 not get exported from the library to the program that loaded it. They will
  361 still be in your ordinary data and BSS sections, so you can access them in
  362 the same way as local variables, using the above <code>..gotoff</code>
  363 mechanism.</p>
  364 <p>Note that due to a peculiarity of the way BSD <code>a.out</code> format
  365 handles this relocation type, there must be at least one non-local symbol
  366 in the same section as the address you're trying to access.</p>
  367 <h4 id="section-10.2.3">10.2.3 Finding External and Common Data Items</h4>
  368 <p>If your library needs to get at an external variable (external to the
  369 <em>library</em>, not just to one of the modules within it), you must use
  370 the <code>..got</code> type to get at it. The <code>..got</code> type,
  371 instead of giving you the offset from the GOT base to the variable, gives
  372 you the offset from the GOT base to a GOT <em>entry</em> containing the
  373 address of the variable. The linker will set up this GOT entry when it
  374 builds the library, and the dynamic linker will place the correct address
  375 in it at load time. So to obtain the address of an external variable
  376 <code>extvar</code> in <code>EAX</code>, you would code</p>
  377 <pre>
  378         mov     eax,[ebx+extvar wrt ..got]
  379 </pre>
  380 <p>This loads the address of <code>extvar</code> out of an entry in the
  381 GOT. The linker, when it builds the shared library, collects together every
  382 relocation of type <code>..got</code>, and builds the GOT so as to ensure
  383 it has every necessary entry present.</p>
  384 <p>Common variables must also be accessed in this way.</p>
  385 <h4 id="section-10.2.4">10.2.4 Exporting Symbols to the Library User</h4>
  386 <p>If you want to export symbols to the user of the library, you have to
  387 declare whether they are functions or data, and if they are data, you have
  388 to give the size of the data item. This is because the dynamic linker has
  389 to build procedure linkage table entries for any exported functions, and
  390 also moves exported data items away from the library's data section in
  391 which they were declared.</p>
  392 <p>So to export a function to users of the library, you must use</p>
  393 <pre>
  394 global  func:function           ; declare it as a function 
  395 
  396 func:   push    ebp 
  397 
  398         ; etc.
  399 </pre>
  400 <p>And to export a data item such as an array, you would have to code</p>
  401 <pre>
  402 global  array:data array.end-array      ; give the size too 
  403 
  404 array:  resd    128 
  405 .end:
  406 </pre>
  407 <p>Be careful: If you export a variable to the library user, by declaring
  408 it as <code>GLOBAL</code> and supplying a size, the variable will end up
  409 living in the data section of the main program, rather than in your
  410 library's data section, where you declared it. So you will have to access
  411 your own global variable with the <code>..got</code> mechanism rather than
  412 <code>..gotoff</code>, as if it were external (which, effectively, it has
  413 become).</p>
  414 <p>Equally, if you need to store the address of an exported global in one
  415 of your data sections, you can't do it by means of the standard sort of
  416 code:</p>
  417 <pre>
  418 dataptr:        dd      global_data_item        ; WRONG
  419 </pre>
  420 <p>NASM will interpret this code as an ordinary relocation, in which
  421 <code>global_data_item</code> is merely an offset from the beginning of the
  422 <code>.data</code> section (or whatever); so this reference will end up
  423 pointing at your data section instead of at the exported global which
  424 resides elsewhere.</p>
  425 <p>Instead of the above code, then, you must write</p>
  426 <pre>
  427 dataptr:        dd      global_data_item wrt ..sym
  428 </pre>
  429 <p>which makes use of the special <code>WRT</code> type <code>..sym</code>
  430 to instruct NASM to search the symbol table for a particular symbol at that
  431 address, rather than just relocating by section base.</p>
  432 <p>Either method will work for functions: referring to one of your
  433 functions by means of</p>
  434 <pre>
  435 funcptr:        dd      my_function
  436 </pre>
  437 <p>will give the user the address of the code you wrote, whereas</p>
  438 <pre>
  439 funcptr:        dd      my_function wrt ..sym
  440 </pre>
  441 <p>will give the address of the procedure linkage table for the function,
  442 which is where the calling program will <em>believe</em> the function
  443 lives. Either address is a valid way to call the function.</p>
  444 <h4 id="section-10.2.5">10.2.5 Calling Procedures Outside the Library</h4>
  445 <p>Calling procedures outside your shared library has to be done by means
  446 of a <em>procedure linkage table</em>, or PLT. The PLT is placed at a known
  447 offset from where the library is loaded, so the library code can make calls
  448 to the PLT in a position-independent way. Within the PLT there is code to
  449 jump to offsets contained in the GOT, so function calls to other shared
  450 libraries or to routines in the main program can be transparently passed
  451 off to their real destinations.</p>
  452 <p>To call an external routine, you must use another special PIC relocation
  453 type, <code>WRT ..plt</code>. This is much easier than the GOT-based ones:
  454 you simply replace calls such as <code>CALL printf</code> with the
  455 PLT-relative version <code>CALL printf WRT ..plt</code>.</p>
  456 <h4 id="section-10.2.6">10.2.6 Generating the Library File</h4>
  457 <p>Having written some code modules and assembled them to <code>.o</code>
  458 files, you then generate your shared library with a command such as</p>
  459 <pre>
  460 ld -shared -o library.so module1.o module2.o       # for ELF 
  461 ld -Bshareable -o library.so module1.o module2.o   # for BSD
  462 </pre>
  463 <p>For ELF, if your shared library is going to reside in system directories
  464 such as <code>/usr/lib</code> or <code>/lib</code>, it is usually worth
  465 using the <code>-soname</code> flag to the linker, to store the final
  466 library file name, with a version number, into the library:</p>
  467 <pre>
  468 ld -shared -soname library.so.1 -o library.so.1.2 *.o
  469 </pre>
  470 <p>You would then copy <code>library.so.1.2</code> into the library
  471 directory, and create <code>library.so.1</code> as a symbolic link to it.</p>
  472 </div>
  473 </body>
  474 </html>