Different Ways of Building Woe32 DLLs

Woe32 Introduction

• msvc (the Win32 API with the MSVC C/C++ compiler),
• mingw (the Win32 API with the gcc compiler),
• cygwin (a POSIX API with the gcc compiler),
• maybe others: pw32, ...

• MFLAGS=-ML (the default)  Single-threaded, statically linked - libc.lib

• MFLAGS=-MT                Multi-threaded, statically linked  - libcmt.lib

• MFLAGS=-MD                Multi-threaded, dynamically linked - msvcrt.lib

ELF Introduction

gcc -shared -o libfoo.so obj1.o obj2.o ...

• a relocation phase at startup time,
• special sections containing indirections, called PLT and GOT.

ELF and variables

extern int samelibvar[5];

extern int externvar[5];

int get_samelibvar() { return samelibvar[1]; }

int get_externvar() { return externvar[1]; }

get_samelibvar:
        call    .L2
.L2:
        popl    %ecx
        addl    $_GLOBAL_OFFSET_TABLE_+[.-.L2], %ecx
        movl    samelibvar@GOT(%ecx), %eax
        movl    4(%eax), %eax
        ret

get_externvar:
        call    .L4
.L4:
        popl    %ecx
        addl    $_GLOBAL_OFFSET_TABLE_+[.-.L4], %ecx
        movl    externvar@GOT(%ecx), %eax
        movl    4(%eax), %eax
        ret

        leal    _GLOBAL_OFFSET_TABLE_-get_externvar(%eip), %ecx

1. The code for both variables is the same. This is because samelibvar could actually be overridden by another samelibvar in the executable! The compiler therefore has no room for optimization. (Better optimizations are possible, with gcc-4's -fvisibility option, but it requires source code modifications.)
2. The code fetches the address of the variable externvar from a pointer-wide memory location, symbolically denoted externvar@GOT, in the current shared library's GOT. There is an externvar@GOT in every shared library that uses the variable; at runtime they all point to the same memory location.
   

Woe32 and variables

extern __declspec(dllexport) int samelibvar[5];

extern __declspec(dllimport) int externvar[5];

_get_samelibvar:
        movl    _samelibvar+4, %eax
        ret

_get_externvar:
        movl    __imp__externvar, %eax
        movl    4(%eax), %eax
        ret

1. The code for the samelibvar access is optimized. No indirection is needed, since the variable resides in the same library.
2. The code fetches the address of the variable externvar from a pointer-wide memory location called _imp__externvar. As in the ELF case, there may be many of these _imp__externvar variables, but they all point to the same externvar.
   

"Premature optimization is the root of all evil." -- Donald Erwin Knuth

1. The code for get_samelibvar is the same as when no __declspec had been given at all. It's the default code. In other words, __declspec(dllexport) does not immediately lead to different code generation. Rather, its primary purpose is that when the variable is actually defined, it will be marked as "exported" in the object file and likewise later in the shared library.
   
2. The code for get_externvar is longer than the code for get_samelibvar. This makes it impossible to convert from the default assembly code to this one in the linker. (In theory this would be possible. Techniques like "linker relaxation" allow to change code in the linker. But the compiler has to know that it must not simplify the difference of two addresses of labels in the same function to a numeric constant, but rather leave that to the linker. But then you have a different object file format than PE. [Object file format such as ELF-Xtensa can store the difference of two addresses in a symbolic way.]) In other words, the __declspec(dllimport) is necessary for the compiler to generate the correct code.

extern __declspec(dllexport) int samelibfunc();

extern __declspec(dllimport) int externfunc();

int get_samelibfunc() { return samelibfunc(); }

int get_externfunc() { return externfunc(); }

_get_samelibfunc:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        call    _samelibfunc
        leave
        ret

_get_externfunc:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        call    *__imp__externfunc
        leave
        ret

_get_samelibfunc:
        pushl   %ebp
        movl    %esp, %ebp
        call    _samelibfunc
        popl    %ebp
        ret

_get_externfunc:
        pushl   %ebp
        movl    %esp, %ebp
        call    *__imp__externfunc
        popl    %ebp
        ret

_externfunc:
        jmp     *__imp__externfunc

Woe32 problem summary

1. You must ensure that the relevant functions and variables are exported from the library.
2. You must ensure that variables imported from other shared libraries are known as __declspec(dllimport).

Woe32 problem 1: Exports

1. Export them all. This works only when using the GNU linker, not (IIRC) when using the MS linker. The linker option that triggers this is called --export-all-symbols. It is also the default behaviour if no symbol is explicitly exported, i.e. if the library would otherwise have no exported symbols.
2. Export a selected set of symbols. How?
   
   1. By use of __declspec(dllexport) in the declaration or the definition of each such symbol.
   2. By use of asm statements that write into the .drectve section:
      

      asm (".section .drectve\n");
      asm (".ascii \" -export:variable,data\"\n");

      for a variable,

      asm (".section .drectve\n");
      asm (".ascii \" -export:function\"\n");

      for a function. This works only when using GCC, not MSVC.
   3. By use of an export list. This is a .def file that has, in particular, an EXPORTS statement followed by a list of all exported symbols.

Woe32 problem 2: Exported variables

1. Don't export variables at all. Export only functions from the shared library.
2. Use the GNU ld --enable-auto-import option.  It is the default on Cygwin since July 2005.
3. Define a macro that expands to  __declspec(dllexport)  when building the library and to  __declspec(dllimport)  when building code outside the library, and use it in all header files of the library that define variables.
4. Define a macro that expands to  __declspec(dllimport)  always, and use it in all header files of the library that define variables.
   

• It produces executables and shared libraries with relocations in the .text segment, defeating the principles of virtual memory. (On ELF systems, relocations in the .text segment are avoided by compiling shared library code as PIC and code of the main executable with absolute addresses. On platforms using the PE format, relocations in the .text segment are present, but are usually not executed, because each shared library is compiled with a random base address, in an attempt to minimize the need to relocate. [Relocation is only needed when without relocation the address ranges occupied by two shared libraries would overlap.])
  
• For some constructs such as
  

  extern int var;
  int * const b = &var;

  it creates an executable that will give an error at runtime, rather than either a compile-time or link-time error or a working executable. (This is with both gcc and g++.) Whereas this code, not relying on auto-import:
  

  extern __declspec(dllimport) int var;
  int * const b = &var;

  gives a compile-time error with gcc and works with g++.
• It doesn't work in some cases (references to a member field of an exported struct variable, or to a particular element of an exported array variable), requiring code modifications. Again one platform dictates code modifications on all platforms.
  

1. the header files are unique to this library (not shared with other packages), and
2. the library sources are contained in one directory, making it easy to define a -DBUILDING_LIBXYZ flag for the library. Example:
   

   #ifdef BUILDING_LIBASPRINTF
   # define LIBASPRINTF_DLL_EXPORTED __declspec(dllexport)
   #else
   # define LIBASPRINTF_DLL_EXPORTED __declspec(dllimport)
   #endif

The catch

1. the compiler signals warnings, making the developer think that he is on the wrong path,
2. libtool fails to handle self-references, i.e. references to a symbol from within the shared library that exports the symbol lead to a link error.
   

Libtool suggestion

GCC suggestion

Resources