On 10/23/07, vibi <vibi_sreenivasan@xxxxxxx> wrote: > On Tue, 2007-10-23 at 08:58 +0200, Steve Graegert wrote: > > On 10/23/07, vibi <vibi_sreenivasan@xxxxxxx> wrote: > > > On Tue, 2007-10-23 at 07:14 +0200, Steve Graegert wrote: > > > > On 10/23/07, vibi <vibi_sreenivasan@xxxxxxx> wrote: > > > > > > "The init code used to set up the main program doesn't care about threads, > > > > > > > > > > because it assumes that they won't be used anyway." > > > > > > > > > > when is init code linked to the program ,during the compile time or > > > > > during the run time? > > > > > > > > It's being added by the linker at compile time. > > > > > > > > \Steve > > > > > > the application you gave earlier is linked without any knowledge of > > > multi-threading > > > so > > > > > > > cc test.c > > > > ./a.out > > > > > > would fail > > > > > > but you also said > > > > > > > cc test.c > > > > LD_PRELOAD=/usr/lib/libpthread.so ./a.out > > > > > > will not fail > > > > > > in both the cases same init code is added at compile time and you also > > > said that init code determines whether a program is multi-threaded. > > > > > > So i am a little bit confused because how at run time the init code is > > > changed. > > > > Linkage takes place at compile time and run time. When starting a > > program its execution environment is setup properly including loading > > and linking in all libraries (including those specified on the command > > line with LD_PRELOAD and at compile time). > > > > The LD_PRELOAD environment variable allows you to load additional > > shared libraries at program startup. The loader ld.so.1, loads the > > specified shared libraries as if the program had been linked > > explicitly with the shared libraries in LD_PRELOAD before any other > > dependents of the program. At startup time, the loader implicitly > > loads one or more libraries, if found, specified in the LD_PRELOAD > > environment. It uses the same load order and symbol resolution order > > as if the library had been explicitly linked as the first library in > > the link line when building the executable. > > > > As a result, at startup the program is multi-threaded when > > LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is > > neither specified at compile time nor __before__ startup of the main > > program (i.e. LD_PRELOAD) the execution environment is unchanged (not > > threaded at all). > > > > This is possible because the init code of the libraries is executed at > > before control is transfered to the main program, thus the program is > > multi-threaded although libpthread has no been specified at compile > > time and no thread-related function calls are made during runtime. > > > > \Steve > > so init code is just like a stub which is resolved while setting up the > execution environment of the program,ie linkage resolution at load time. > > am i understanding correctly. Well, it's not a stub, since it's a very important section of the executable. The .init section holds executable instructions that contribute to the process initialization code. That is, when a program starts to run the system arranges to execute the code in this section before the main program entry point (main() in C programs). The .init and .fini sections have a special purpose. If a function is placed in the .init section, the system will execute it before the main function. Also the functions placed in the .fini section will be executed by the system after the main function returns. This feature is utilized by compilers to implement global constructors and destructors in C++. Also, any shared object file included in the program also has an opportunity to run its initialization code before the call to the main program. \Steve -- Steve Grägert DigitalEther.de - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
