This is the mail archive of the
mailing list for the glibc project.
Re: libc.so, dynamic and executable?
- From: "Ryan Arnold" <ryan dot arnold at gmail dot com>
- To: "Nathan Weyer" <nathanw at meritind dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 12 May 2008 12:46:40 -0500
- Subject: Re: libc.so, dynamic and executable?
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YdqDzfdzy2PiD70kqqNhwkb0/6V0qZg4WP8Qun07mq4=; b=PdJ9sRemrSNjZ5ZeGDBsvYyA92pqmhWn7Y6HmLmsn0qZsRYjvLiRXQb19WW0cGgKmsvrhm8o1qMd7XToQo2AtoDs9Vjcyn/Nsn42nuyxcBWrMRi6FSgZxJ+xIqtLBagKyGPx3Vm0qsDqmprkkOBQzX6GmJEu7SKVjbNlOazxNcE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=voDi6AYAnDIZfI72PoS6HkJVZvdxhbXNB3MSJbuUnzHbwAWGDvoVJE36XSkjnEUGqRuZuugJfzJgtqkWZW53XEolGP2K4iRQ59cl9mLCh6D34AZxO5BccHVT80xD8JsHSb0W+UHL8uTXZjeVfS+yK7HiIBYN1C/U7xoC94a40TI=
- References: <firstname.lastname@example.org>
On Mon, May 12, 2008 at 10:19 AM, Nathan Weyer <email@example.com> wrote:
> Well, the list said any question....
> I am curious if anyone can explain how glibc manages the trick of being both a
> executable binary and a loadable module at the same time? I was under the
> impression that dlopen didn't work on anything that could run on it's own.
Which application and/or library provided by GLIBC are you referring to?
When a user application is compiled it has the program interpreter
(the dynamic linker/loader ld.so) information [the path] embedded in
the program's ELF header. Of course this isn't the case with
statically link applications since you don't need a dynamic linker and
no libraries are loaded after the fact.
As far as I understand, the kernel loads the application and the
indicated dynamic linker/loader into memory. It passes control to the
loader which will load the libc.so library and resolve necessary early
symbols. Control will pass to libc to execute the application init
code which will launch the application.
The libc.so library does have a 'main' entry point but it is compiled
as a shared object, not an executable.
Run readelf -l <executable or shared object> | grep "Elf file type"
against an executable and you'll see:
Elf file type is EXEC (Executable file)
For a shared object you'll see:
Elf file type is DYN (Shared object file)
Ryan S. Arnold