This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: loading of shared objects and executables
- From: "Bolshakov, Roman" <Roman dot Bolshakov at emc dot com>
- To: Michael Zintakis <michael dot zintakis at googlemail dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Sat, 27 Oct 2012 18:51:22 +0000
- Subject: RE: loading of shared objects and executables
- References: <508B1C99.8070400@googlemail.com>
Hi Mike,
> 2. Once I've done that, if there is a possibility to identify all .so
> (shared objects) on which this executable depends (by looking at its
> headers for example), I could do the same as step 1 above for all
> dependent .so files. If not, then I'll have to pass control to ld.so and
> intercept the point prior to where these .so are about to be loaded, so
> that I could do the verification - as in step one above, but for the
> shared objects. If everything checks out, then I'll pass control over to
> ld.so.
I'm only not sure if the kernel know all the sorts of ELF sections and segments ld.so can handle.
Probably you'll need to modify kernel code to walk over DYNAMIC segment (which keeps the list
of dependencies) to verify the shared objects an application depends on.
> I am guessing the picture when statically compiled executables are run
> is more or less the same with the exception of loading ÑÑÐ shared
> libraries, as they are included as part of the file which needs to be
> executed - am I correct in thinking that?
Yes, but a statically linked executable can also call dlopen(), mmap() (As it was noted later).