RE: Startup function before main.

RE: Startup function before main.

[krishna.vamsi]

This is aimed at learning at Learning Linux Environment and c language.
To Get to know better.

I want to create inter process communication environment where every
process is linked to a symbol table. This linking is done through
Startup routine before main. The communication is achieved by modifying
or Adding new entries to the Symbol Table.

This is very much analogous to the Linux Kernel Symbol Table Concept
where every module can use its symbol table. My effort is to create the
similar environment.


-Vamsi
-----Original Message-----
From: Uday Karan [mailto:uday.karan@gmail.com] 
Sent: Monday, March 27, 2006 5:32 PM
To: Vamsi Krishna (WT01 - Wireless Networks and Devices)
Cc: linux-c-programming@vger.kernel.org
Subject: Re: Startup function before main.


I really don't understand what is the need to have a
initialization/start up routine before main().  Main is just like any
other function except that it works as a default entry point to which
the glibc start up code makes a call to.

You can have a function main() as your start up routine that calls your
application's main functions app_main() or something similar. 
You can do all your start up code in main itself and then call
app_main().

Simulating what you are trying to achieve here should not be very
difficult.  You can tweak your environment and stuff in main().

On 3/27/06, krishna.vamsi@wipro.com <krishna.vamsi@wipro.com> wrote:
> Hi List,
>
> Before Executing the main function, a startup routine will be executed

> which will set up the initial environment for the process.
>
> This Startup routine will be supplied by the kernel and linked by the 
> Linker. My question is : Can we add one more startup routine before 
> executing the main program, if yes how??
>
>
> -Vamsi
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-c-programming" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
>

Startup function before main.

[krishna.vamsi]

Hi List,
 
Before Executing the main function, a startup routine will be executed
which will set up the initial environment for the process.
 
This Startup routine will be supplied by the kernel and linked by the
Linker. My question is : Can we add one more startup routine before
executing the main program, if yes how??
 
 
-Vamsi

Re: Startup function before main.

[Steve Graegert]

On 3/27/06, krishna.vamsi@wipro.com <krishna.vamsi@wipro.com> wrote:
> Hi List,
>
> Before Executing the main function, a startup routine will be executed
> which will set up the initial environment for the process.
>
> This Startup routine will be supplied by the kernel and linked by the
> Linker. My question is : Can we add one more startup routine before
> executing the main program, if yes how??

No, not programmatically, only by patching the executable or object file.
You can call other functions from within the constructor:

	void __attribute__ ((constructor)) my_ctor() {
		int i = my_func();
	}

You should not need a second constructor.  Who shall decide which one
comes first and how should it be done?

	\Steve

Re: Startup function before main.

[Uday Karan]

I really don't understand what is the need to have a
initialization/start up routine before main().  Main is just like any
other function except that it works as a default entry point to which
the glibc start up code makes a call to.

You can have a function main() as your start up routine that calls
your application's main functions app_main() or something similar. 
You can do all your start up code in main itself and then call
app_main().

Simulating what you are trying to achieve here should not be very
difficult.  You can tweak your environment and stuff in main().

On 3/27/06, krishna.vamsi@wipro.com <krishna.vamsi@wipro.com> wrote:
> Hi List,
>
> Before Executing the main function, a startup routine will be executed
> which will set up the initial environment for the process.
>
> This Startup routine will be supplied by the kernel and linked by the
> Linker. My question is : Can we add one more startup routine before
> executing the main program, if yes how??
>
>
> -Vamsi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Startup function before main.

[Steve Graegert]

On 3/27/06, Uday Karan <uday.karan@gmail.com> wrote:
> I really don't understand what is the need to have a
> initialization/start up routine before main().  Main is just like any
> other function except that it works as a default entry point to which
> the glibc start up code makes a call to.
>
> You can have a function main() as your start up routine that calls
> your application's main functions app_main() or something similar.
> You can do all your start up code in main itself and then call
> app_main().
>
> Simulating what you are trying to achieve here should not be very
> difficult.  You can tweak your environment and stuff in main().

init-like constructors can be very helpful in some situations, like
profiling.  It allows for preparation of the environment, loading of
libraries and the like.  Doing that when main() has already been
called is not sufficient in these cases.

	\Steve

Re: Startup function before main.

[Glynn Clements]

krishna.vamsi@wipro.com wrote:

> Before Executing the main function, a startup routine will be executed
> which will set up the initial environment for the process.
>  
> This Startup routine will be supplied by the kernel

That's incorrect. The kernel's job ends at the point that it inkokes
the loader.

> and linked by the
> Linker. My question is : Can we add one more startup routine before
> executing the main program, if yes how??

Apart from the approach suggested by Steve, you can replace the
run-time startup file (crtbegin.o etc) with your own file (use gcc's
-nostartfiles option), or use your own loader in place of
ld-linux.so.2 (store the name of the loader in the .interp section of
the executable).

-- 
Glynn Clements <glynn@gclements.plus.com>