Dynamic shared library

deepak <deepakpjose.DeleteThis@gmail.com> writes:
> Where the dynamic shared library be stored in a normal C program.
> I heard like it will be in between heap and stack.
>
> So can I image like shared library as a C memory layout
> inside another C memory layout?

Have a look at the output of pmap -d for some running process. A
simple example (a getty on the system I am presently using):

Address Kbytes Mode Offset Device Mapping
08048000 16 r-x-- 0000000000000000 016:00001 getty

This is the so-called 'text segment' of the program.

0804c000 4 rw--- 0000000000003000 016:00001 getty

This is its data segment.

0804d000 140 rw--- 0000000000000000 000:00000 [ anon ]

This is 'the heap', ie the area of virtual memory allocated via brk/
sbrk.

b7efb000 4 rw--- 0000000000000000 000:00000 [ anon ]

Some random memory mapping.

b7efc000 1248 r-x-- 0000000000000000 016:00001 libc-2.7.so

'text segment' of the C-liobrary.

b8034000 4 r---- 0000000000138000 016:00001 libc-2.7.so

Read-only data of the C-library.

b8035000 8 rw--- 0000000000139000 016:00001 libc-2.7.so

'data segement' of the C-library.

Deepak <deepakpjose.TakeThisOut@gmail.com> writes:
> On Sep 23, 4:51 pm, Rainer Weikusat <rweiku....TakeThisOut@mssgmbh.com> wrote:
>> deepak <deepakpj....TakeThisOut@gmail.com> writes:
>> > Where the dynamic shared library be stored in a normal C program.
>> > I heard like it will be in between heap and stack.
>>
>> > So can I image like shared library as a C memory layout
>> > inside another C memory layout?
>>
>> Have a look at the output of pmap -d for some running process. A
>> simple example (a getty on the system I am presently using):
>>
>> Address   Kbytes Mode  Offset           Device    Mapping
>> 08048000      16 r-x-- 0000000000000000 016:00001 getty
>>
>> This is the so-called 'text segment' of the program.
>>
>> 0804c000       4 rw--- 0000000000003000 016:00001 getty
>>
>> This is its data segment.
>>
>> 0804d000     140 rw--- 0000000000000000 000:00000   [ anon ]
>>
>> This is 'the heap', ie the area of virtual memory allocated via brk/
>> sbrk.

[...]

>> b8035000       8 rw--- 0000000000139000 016:00001 libc-2.7.so
>>
>> 'data segement' of the C-library.
>
> so heap section and data section will be shared by library and
> program.

The 'heap' is shared but the 'data sections' (containing objects with
static storage duration aka 'global variables') aren't.

[...]

> For example, I have a printf and instruction jmp/call is present
> in text part of program. And I'm assuming that while loading
> through a stub, printf's address is now pointing to the text part in
> shared library. Is this understanding is correct?

I am not sure that I understand your sentence correctly. The call in
the program transfers ultimatively cause an address to be loaded into
the PC-(program counter)register which is stored in a table being
part of the binary (each 'library function' corresponds with a
particular slot). Before a particular subroutine has been invoked for
the first time, this value points to the symbol resolution routine of
the runtime-linker. That, when invoked, determines the 'runtime
address' of the routine supposed to be called instead, eg, printf,
possibly loading a shared object ('library') if necessary and replaces
the address in the table slot with the 'real' entry point to the
function the program called (and jumps to this address
afterwards).

This is accurate for the IA-32-ABI, but the general principle is the
same on other architectures.

Deepak wrote:

> I would like to know how address is getting resolved while loading.
>
> For example, I have a printf and instruction jmp/call is present
> in text part of program. And I'm assuming that while loading
> through a stub, printf's address is now pointing to the text part in
> shared library. Is this understanding is correct?

Yes.

I write a small program just calling printf():
main(int argc, char *argv[]){ printf("arg=%s\", argv[0]);}
Then I ran gdb on the binary and looked at the code and variables:

* The call to printf in your code is to an indirect jump inside a code
stub statically linked to your program:
0x08048395 <main+33>: call 0x80482d8 <printf@plt>
:
0x80482d8 <printf@plt>: jmp *0x804957c

* this location initialliy points to some code which loads the library
(if required) and resolves printf's address and puts that into that
location:
0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
:
0x80482de <printf@plt+6>: push $0x10
0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
(the code at _init+48 does the loading and resolving)

Then I set a breakpoint *after* the call to printf() and ran the program
until it hit the breakpoint and had another look at the variables and code:

This results in
0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
:
0xb7e4e330 <printf>: push %ebp

So, the next time your prorgam calls printf, it will go there (almost)
directly.

HTH,

Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html

Deepak wrote:

> I would like to know how address is getting resolved while loading.
>
> For example, I have a printf and instruction jmp/call is present
> in text part of program. And I'm assuming that while loading
> through a stub, printf's address is now pointing to the text part in
> shared library. Is this understanding is correct?

Yes.

I wrote a small program just calling printf():

# include <stdio.h>
main(int argc, char *argv[]){ printf("argv[0]=%s\n", argv[0]);}

I compiled to program and ran gdb on the binary to look at the code and
variables:

* The call to printf in the code is to an indirect jump inside a code
stub statically linked to your program:
0x08048395 <main+33>: call 0x80482d8 <printf@plt>
:
0x80482d8 <printf@plt>: jmp *0x804957c

* this location initialliy points to some code which loads the library
(if required) and resolves printf's address and puts that into that
location:
0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
:
0x80482de <printf@plt+6>: push $0x10
0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
(the code at _init+48 does the loading and resolving)

Then I set a breakpoint *after* the call to printf() and ran the program
until it hit the breakpoint and had another look at the variables and code:

This results in
0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
:
0xb7e4e330 <printf>: push %ebp

So, the next time my prorgam would call printf, it will go there
(almost) directly.

HTH,

Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html

> Deepak wrote:
>
>> I would like to know how address is getting resolved while loading.
>>
>> For example, I have a printf and instruction jmp/call is present
>> in text part of program. And I'm assuming that while loading
>> through a stub, printf's address is now pointing to the text part in
>> shared library. Is this understanding is correct?
>
> Yes.
>
> I wrote a small program just calling printf():
>
> # include <stdio.h>
> main(int argc, char *argv[]){ printf("argv[0]=%s\n", argv[0]);}
>
> I compiled to program and ran gdb on the binary to look at the code and
> variables:
>
> * The call to printf in the code is to an indirect jump inside a code stub
> statically linked to your program:
> 0x08048395 <main+33>: call 0x80482d8 <printf@plt>
> :
> 0x80482d8 <printf@plt>: jmp *0x804957c
>
> * this location initialliy points to some code which loads the library (if
> required) and resolves printf's address and puts that into that location:
> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
> :
> 0x80482de <printf@plt+6>: push $0x10
> 0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
> (the code at _init+48 does the loading and resolving)
>
> Then I set a breakpoint *after* the call to printf() and ran the program
> until it hit the breakpoint and had another look at the variables and
> code:
>
> This results in
> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
> :
> 0xb7e4e330 <printf>: push %ebp
>
> So, the next time my prorgam would call printf, it will go there (almost)
> directly.
>
> HTH,
>
> Josef
> --

I am confused that while the first time of calling printf is to cause
the actual address of <printf> put in the

0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330

Could you explain a bit more about how the "next time" of calling
the two intstructions below happen ?

0x08048395 <main+33>: call 0x80482d8 <printf@plt>

0x80482d8 <printf@plt>: jmp *0x804957c


Jason

"pansious" <pansious.TakeThisOut@21cn.com> writes:
Josef Moellers <josef.moellers.TakeThisOut@ts.fujitsu.com> wrotes:

[...]

>> * this location initialliy points to some code which loads the library (if
>> required) and resolves printf's address and puts that into that location:
>> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
>> :
>> 0x80482de <printf@plt+6>: push $0x10
>> 0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
>> (the code at _init+48 does the loading and resolving)
>>
>> Then I set a breakpoint *after* the call to printf() and ran the program
>> until it hit the breakpoint and had another look at the variables and
>> code:
>>
>> This results in
>> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
>> :
>> 0xb7e4e330 <printf>: push %ebp

[...]

> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
>
> Could you explain a bit more about how the "next time" of calling
> the two intstructions below happen ?
>
> 0x08048395 <main+33>: call 0x80482d8 <printf@plt>
>
> 0x80482d8 <printf@plt>: jmp *0x804957c

The jmp transfers control to the address stored at 0x804957c. This
address is now 0xb7e4e330, this being the entry point of printf.
Consequently, executing a subroutine invocation ('call') transfering
to location 0x80482d8 causes an unconditional branch/ jump to the
print-routine in the C-library.

Josef Moellers <josef.moellers.DeleteThis@ts.fujitsu.com> writes:

[...]

> * this location initialliy points to some code which loads the library
> (if required) and resolves printf's address and puts that into that
> location:
> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
> :
> 0x80482de <printf@plt+6>: push $0x10
> 0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
> (the code at _init+48 does the loading and resolving)
>
> Then I set a breakpoint *after* the call to printf() and ran the
> program until it hit the breakpoint and had another look at the
> variables and code:
>
> This results in
> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
> :
> 0xb7e4e330 <printf>: push %ebp
>
> So, the next time my prorgam would call printf, it will go there
> (almost) directly.

It will go there 'almost' indirectly, since there is first a direct
control transfer program -> plt and then an indirect control
transfer plt -> libc. This implies that calling a routine in a shared
object is both more expensive than a direct function and more
expensive than an indirect jump.

Calling this 'almost directly' is something the nice German term
'Etikettenschwindel' refers to .

"Rainer Weikusat" <rweikusat.TakeThisOut@mssgmbh.com>
??????:874oqif1cq.fsf@fever.mssgmbh.com...
> "pansious" <pansious.TakeThisOut@21cn.com> writes:
> Josef Moellers <josef.moellers.TakeThisOut@ts.fujitsu.com> wrotes:
>
> [...]
>
>>> * this location initialliy points to some code which loads the library
>>> (if
>>> required) and resolves printf's address and puts that into that
>>> location:
>>> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de
>>> :
>>> 0x80482de <printf@plt+6>: push $0x10
>>> 0x80482e3 <printf@plt+11>: jmp 0x80482a8 <_init+48>
>>> (the code at _init+48 does the loading and resolving)
>>>
>>> Then I set a breakpoint *after* the call to printf() and ran the program
>>> until it hit the breakpoint and had another look at the variables and
>>> code:
>>>
>>> This results in
>>> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
>>> :
>>> 0xb7e4e330 <printf>: push %ebp
>
> [...]
>
>> 0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330
>>
>> Could you explain a bit more about how the "next time" of calling
>> the two intstructions below happen ?
>>
>> 0x08048395 <main+33>: call 0x80482d8 <printf@plt>
>>
>> 0x80482d8 <printf@plt>: jmp *0x804957c
>
> The jmp transfers control to the address stored at 0x804957c. This
> address is now 0xb7e4e330, this being the entry point of printf.
> Consequently, executing a subroutine invocation ('call') transfering
> to location 0x80482d8 causes an unconditional branch/ jump to the
> print-routine in the C-library.


Yes, this is what happens when calling printf() the second time.

main() { printf("?"); /* first time*/
printf("?; /* second time, without going through the resoving
process */ }

My understaning is the first time calling printf, not only
0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0x080482de

is replaced with

0x804957c <_GLOBAL_OFFSET_TABLE_+20>: 0xb7e4e330

the replacing address should also be transferred to execute.
Actually I was asking for a little detail of this step.
I guess this is implemented right after the address resolution phase.

I have 3 more questions wondering ture or false:

1. the run-time linker should be the same for every dynamic linked
executables in a system ?

2. if 1 is true, exec() should not repace the part containing the run-time
linker ?

3. when the run-time linker tries load any library module for a process,
the kernel vm will
check if it's been loaded, and if loaded, that library module would be
shared and simply
mapped to one more process's address space.


Thanks.

In article <ha5agd$189$1@www.shinco.com>, pansious <pansious.TakeThisOut@21cn.com> wrote:
>
>I have 3 more questions wondering ture or false:
>
>1. the run-time linker should be the same for every dynamic linked
>executables in a system ?

That's false. The dynamic linker is specified in the .interp section of an
ELF exectuable, so each exectuable can choose a different dynamic linker if
it wants to.

Normally the dynamic linker will be the one that came with your libc, but
it's possible to have more than one libc. For example on a mostly-glibc
system you might have a few programs linked to uclibc, or some old relics
linked to libc5.

>
>2. if 1 is true, exec() should not repace the part containing the run-time
>linker ?

That would be an invalid optimization since 1 is not true. And probably not
worth doing even if it was valid.

--
Alan Curry