Even said:
Hi all,
As far as I know, relative address will be assigned by program at link
time.Right? Ok, here we go.
'relative' is not a good term here.
So if we use a static library, it will give the program an relative
address(i mean the function address) at link time.
Also the code of the library will load into the program. Go on.
yeah, at link time, all the code and data from the library goes into the
binary, which is part of why using lots of static libs tends to produce
large binaries...
the code in the app is linked directly to the code in the library, just the
same as with local code.
Now if we use a dynamic library, what it will give the program?
A symbolic? or Address ?
it depends.
if it is a symbolic, when does the symbolic change to an address? and
How does it load its code to the program?
this depends on the OS.
note that there may be errors here, all this is not something I have looked
into in too much detail.
on linux and friends, it will produce a binary that is like "oh well, I am
not fully linked, load these libraries on loading". so, the loader will also
grab the libraries, and resolve the addresses to the addresses in the
library (internally, this will look about the same as if the app had used a
static library).
the exact mechanics of this process are not something I will really go into.
note that in linux, these libs tend to use position-independent-code, which
is fun, since the same library pages can be shared between different
processes, and located at different locations in each (GOT magic...). in
windows, however, DLLs are typically fixed-address to allow sharing
(relocating DLLs is also possible, but they end up having their own pages in
each process...).
now, I think, DLLs are a little different.
as far as I understand it, with DLLs you end up with a number of proxy
functions, which jump into the function through a jump table.
so, at load time, the app is loaded, and either the loader (or part of the
app's runtime, or at least, I think this is how it worked at one time) sees
that a DLL is needed, so it loads the DLL and fills in the various slots in
the table.
in the past, this was done via import libraries (a special tool was used to
make a static library from the DLL), but (at least for GNU-ld), all this
magic is done by the linker itself.
but, none of this is anything I have really looked into in too much
detail...