This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Library mapping
- From: "Martin v. Loewis" <martin at v dot loewis dot de>
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Cc: glibc-linux at ricardo dot ecn dot wfu dot edu
- Date: Fri, 14 Dec 2001 00:34:48 +0100
- Subject: Re: Library mapping
- References: <3C187222.8010701@bilten.metu.edu.tr>
- Reply-to: glibc-linux at ricardo dot ecn dot wfu dot edu
> I'm watching through /proc/<pid>/maps on my Linux 2.4.3 computers that
> the same program gets its libraries (and their data segments) mapped to
> different locations on virtual memory. The same OS configuration and
> libraries are installed on a (1) Pentium 225 and a (2) Pentium III.
When you say "the same", do you mean "the very same", i.e. with no
differences whatsoever in md5sums of all shared libraries? Including
ld-linux.so.2?
> I'm a compiling the program on (1) and executing on both of them. I'm
> expecting to see their /proc/<pid>/maps be the same for the same point
> in the program. But they are not. Might this be because of their
> hardware differences?
No, it is rather because differences in the environment (in a general
sense). Things that may contribute:
- exact setting of the enviroment variables (in the strict sense of
execve)
- size, contents, and layout of /etc/ld.so.cache
- path name of each file that is being loaded
- contents of each directory that is searched when loading shared libraries,
and exact order of entries returned by getdents(2)
- value of cwd string
> When a program compiled (non-statically), are the locations where
> shared objects are mapped known at compile time or are they resolved
> at load time by ld.so?
They are resolved by ld.so, on a first-come-first-served basis.
> Note: I'm doing some low level stuff to overwrite the data segments
> for libraries after loading.
Then you better use the source, Luke.
Regards,
Martin