Skip to contentSkip to conversation

dso loading question

DISCUSSION Kanoj Sarcar 3 participants 3 messages May 27, 1999 Memory management

lore
Share & tools
lore

Kanoj Sarcar

author
#0 lore raw

I am trying to understand how the glibc ld-linux code works just after program startup. I have a small program

main()
{
}

on which I ran strace to get the following output:

[kanoj@entity /tmp]$ strace ./a.out execve("./a.out", ["./a.out"], [/* 18 vars */]) = 0

brk(0)                                  = 0x8049558
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0

mmap(0, 11908, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000b000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000e000
munmap(0x4000e000, 4096) = 0
mmap(0, 670420, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000e000 mprotect(0x4009f000, 76500, PROT_NONE) = 0

mmap(0x4009f000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x90000) = 0x4009f000
mmap(0x400a6000, 47828, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400a6000
close(3)                                = 0
personality(PER_LINUX)                  = 0
getpid()                                = 9822
_exit(134513792)                        = ?

Here are the questions I would like to get answers to:
1. What is the purpose of the /etc/ld.so.cache? Where can I learn more about it?
2. I assume the first 4K mmap of libc is to read section headers etc ... or is there something more going on there?
3. How are the libc mmap/munmap calls made by the loading code? Basically, how does the code decide on the offset/length to mmap? Why is an mprotect being done?
4. Are the .init sections of the dso's executed before the close() of the fd referencing the dso?
5. At what point is the personality(PER_LINUX) call made?

I am trying to understand how dso loading works in Linux, specially at program startup time.

Thanks for any input. Please CC me on any responses at [email protected].

Kanoj
[email protected]

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

#1 lore raw
Quoted 4 lines

[kanoj@entity /tmp]$ strace ./a.out execve("./a.out", ["./a.out"], [/* 18 vars */]) = 0
brk(0) = 0x8049558
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)

lists dso's to link before any other dynamic linking occurs; useful for overriding, say, malloc().

Quoted 1 line

open("/etc/ld.so.cache", O_RDONLY) = 3

Contains a cache of where dso's are located on the disk, so the dynamic linker doesn't have to search for them.

Quoted 2 lines

I am trying to understand how dso loading works in Linux, specially at program startup time.

You might want to look at the source...

Signature · 11 lines
Kevin L. Mitchell <[email protected]>
-------------------------  -. .---- --.. ..- -..-  --------------------------
http://web.mit.edu/klmitch/www/               (PGP keys availiable from here)
    RSA AE87D37D/1024:  DE EA 1E 99 3F 2B F9 23  A0 D8 05 E0 6F BA B9 D2
    DSS ED0DB34E/1024: D9BF 0E74 FDCB 43F5 C597  878F 9455 EC24 ED0D B34E
    DH  2A2C31D4/2048: 1A77 4BA5 9E32 14AE 87DA  9FEC 7106 FC62 2A2C 31D4

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to [email protected].  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
#2 lore raw
In reply to Kanoj Sarcar
Quoted 29 lines · Kanoj Sarcar

I am trying to understand how the glibc ld-linux code works just after program startup. I have a small program

main()
{
}

on which I ran strace to get the following output:

[kanoj@entity /tmp]$ strace ./a.out execve("./a.out", ["./a.out"], [/* 18 vars */]) = 0

brk(0)                                  = 0x8049558
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0

mmap(0, 11908, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000b000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000e000
munmap(0x4000e000, 4096) = 0
mmap(0, 670420, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000e000 mprotect(0x4009f000, 76500, PROT_NONE) = 0

mmap(0x4009f000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x90000) = 0x4009f000
mmap(0x400a6000, 47828, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400a6000
close(3)                                = 0
personality(PER_LINUX)                  = 0
getpid()                                = 9822
_exit(134513792)                        = ?
Quoted 3 lines

Here are the questions I would like to get answers to:
1. What is the purpose of the /etc/ld.so.cache? Where can I learn more about it?

Libraries may be spread of a large number of directories. ld.so.cache is used to shorten this search process.

Quoted 2 lines

2. I assume the first 4K mmap of libc is to read section headers etc ... or is there something more going on there?

Only the ELF header is guaranteed to be at offset 0. All there rest is accessed via the segment map. My libc looks like:

Program Header:

    PHDR off    0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
         filesz 0x000000a0 memsz 0x000000a0 flags r-x
  INTERP off    0x000d408d vaddr 0x000d408d paddr 0x000d408d align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
         filesz 0x000d40a0 memsz 0x000d40a0 flags r-x
    LOAD off    0x000d40a0 vaddr 0x000d50a0 paddr 0x000d50a0 align 2**12
         filesz 0x00004068 memsz 0x00006f48 flags rw-
 DYNAMIC off    0x000d8058 vaddr 0x000d9058 paddr 0x000d9058 align 2**2
         filesz 0x000000b0 memsz 0x000000b0 flags rw-

Best enjoy this with an ELF spec on your desk.

Quoted 3 lines

3. How are the libc mmap/munmap calls made by the loading code? Basically, how does the code decide on the offset/length to mmap? Why is an mprotect being done?

mprotect calls may be necessary for mapping areas which are mapped without write access but where relocations need to be applied to.

Quoted 6 lines

4. Are the .init sections of the dso's executed before the close() of the fd referencing the dso?
5. At what point is the personality(PER_LINUX) call made?

I am trying to understand how dso loading works in Linux, specially at program startup time.

Read glibc/sysdeps/unix/sysv/linux/init-first.c. Actually the entire startuped & libc initialization code. It's quite complex.

Btw, this all is done in userspace, therefore nothing for linux-kernel or linux-mm.

Ralf
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/