|Supporting Dynamic Linking email@example.com (Robbert Haarman) (2010-11-21)|
|Re: Supporting Dynamic Linking firstname.lastname@example.org (Ian Lance Taylor) (2010-11-22)|
|From:||Ian Lance Taylor <email@example.com>|
|Date:||Mon, 22 Nov 2010 08:37:30 -0800|
|Posted-Date:||26 Nov 2010 23:28:08 EST|
Robbert Haarman <firstname.lastname@example.org> writes:
> One of the features I am currently working on for Voodoo is making
> currently being worked on is making the Voodoo compiler emit code
> suitable for use in dynamic libraries. The main impediment here is that
> the linker likes to know the size of objects in a dynamic library, but
> Voodoo does not currently provide this information.
To know what you should provide for the size, consider what the dynamic
linker is going to use the information for. If a shared library defines
a global variable, and an executable refers directly to it, then the
variable must be copied into the executable's memory space. This is
because the executable is (normally) not compiled with -fPIC, so the
variable must be at a fixed memory address. The shared library is not
at a fixed memory address.
The linker must know how large the variable should be in the
executable's memory space. For that, it uses the size recorded in the
symbol table. (I won't go into COPY relocs here, since they are
irrelevant with respect to the size.) So you should set the size of the
symbol such that if the linker needs to copy the variable into the main
program, the main program allocates the right amount of memory for it.
When writing in a language above assembly code, the compiler determines
the size of a variable from its declaration. When writing assembler
code, the author is normally require to write a .size pseudo-op to set
Return to the
Search the comp.compilers archives again.