Hi all,

As far as I know, relative address will be assigned by program at link
time.Right? Ok, here we go.

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.

Now if we use a dynamic library, what it will give the program?
A symbolic? or Address ?

if it is a symbolic, when does the symbolic change to an address? and
How does it load its code to the program?


Thanks
Even

Even wrote:
> Hi all,
>
> As far as I know, relative address will be assigned by program at link
> time.Right? Ok, here we go.
>
> 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.
>
> Now if we use a dynamic library, what it will give the program?
> A symbolic? or Address ?
>
> if it is a symbolic, when does the symbolic change to an address? and
> How does it load its code to the program?
>
>
> Thanks
> Even
>

Under the windows system, dynamic link libraries are
relocated to some address at load time. The linker
produces a relocation table that allows loading the
library at any address

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Even <szhang@winbond.com> wrote:

> As far as I know, relative address will be assigned by program at link
> time.Right?

Or wrong. Or pale blue with dots. All this is entirely system-dependent.
It may even be (but possibly isn't) compiler-dependent. You'll have to
ask this question in a newsgroup that specialises in your OS (somewhere
in microsoft.public.*, by the looks of it), and there you'll probably
need to specify which compiler you're using as well.

Richard

"Even" <szhang@winbond.com> wrote in message
news:1192697933.197259.227200@e34g2000pro.googlegr oups.com...
> 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...


>
> Thanks
> Even
>

Thanks for your all reply, especially cr88192.

That is, in linux different processes share the the same code(Dlls),
but in window they copy the code to their space.

Now we have a global variable(g_var) in Dlls, in linux if one process
change the *g_var*, and does it effect another process?

by the way, what's the different between 'load time' and 'running
time'. Does 'OS' control 'load time'?

"Even" <szhang@winbond.com> wrote in message
news:1192760673.817902.310890@t8g2000prg.googlegro ups.com...
> Thanks for your all reply, especially cr88192.
>
> That is, in linux different processes share the the same code(Dlls),
> but in window they copy the code to their space.
>

linux usually shares code. this is because shared-objects tend to be
compiled with position-independent-code.

windows tries to share pages, but does not if the hard-coded address can't
be used (many DLLs are pre-relocated to be loaded at certain addresses...).

> Now we have a global variable(g_var) in Dlls, in linux if one process
> change the *g_var*, and does it effect another process?
>

probably, linux likely handles shared libraries similar to, fork(), namely
that any shared pages are copy-on-write.

> by the way, what's the different between 'load time' and 'running
> time'. Does 'OS' control 'load time'?
>

load time is, when the app is being loaded. runtime generally means
"whenever the app so feels like it".
yes, usually load-time is OS controlled.


or such...

On Fri, 19 Oct 2007 21:29:37 +1000, in comp.lang.c , "cr88192"
<cr88192@nospam.hotmail.com> wrote:

>
>"Even" <szhang@winbond.com> wrote in message
>news:1192760673.817902.310890@t8g2000prg.googlegr oups.com...
>> Thanks for your all reply, especially cr88192.
>>
>> That is, in linux different processes share the the same code(Dlls),
>> but in window they copy the code to their space.
>>
>
>linux usually shares code. this is because shared-objects tend to be
>compiled with position-independent-code.

Would you please stop answering this highly-offtopic question in CLC?
The OP will start to think they can get all their programming
questions answered here, and next time it may be even more wildly
offtopic

>windows tries to share pages, but does not if the hard-coded address can't
>be used (many DLLs are pre-relocated to be loaded at certain addresses...).

And please don't say "well ,where /can/ you ask about windows _and_
linux at the same time" because thats not relevant. I've no idea where
you ask about bondage _and_ buddism at the same time, but that doesn't
make it topical in CLC ....

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan