bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: can't use __libc_start_main() to redirect call to main()


From: Gary Funck
Subject: RE: can't use __libc_start_main() to redirect call to main()
Date: Wed, 14 May 2003 14:52:50 -0700

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Wednesday, May 14, 2003 2:20 PM
> To: Gary Funck
> Cc: address@hidden
> Subject: Re: can't use __libc_start_main() to redirect call to main()
>
>
> "Gary Funck" <address@hidden> writes:
>
> > While developing support for an experimental C language
> dialect, intended
> > for use in parallel computation applications, I ran into a
> problem with the
> > way __libc_start_main() calls the main program. The language definition
> > requires that certain runtime code be run ahead of the user's
> main program.
> > There are various ways this can be implemented. On the initial target
> > platform, SGI Irix, we used the linker's facility to specify an
> alternate
> > entry point via the -e switch. On Irix, this entry is apparently called
> > *after* the C runtime has been initialized, and is thus called with the
> > familiar (argc, argv, env) interface. Thus, it is easy to
> impose the runtime
> > system's "main" program ahead of the user's actual main
> program. On Linux,
> > and probably other Unix systems, the situation isn't so straightforward,
> > because -e <entry> appears to call <entry> as the first code to
> be run when
> > the process begins execution, before the C library environment has been
> > initialized. In Linux, this routine is known as _start and is located in
> > start.S, which in turn is incorporated in gcrt1.o.
>
> Have you considered using an initialisation routine to call this
> routine instead?  Look at __attribute__((constructor)) in GCC.
>

Geoff, thanks. I've used GCC's constructors before, but in this case,
the logic works best if the runtime's initialization is called as if
it were "main" before calling the user's actual main program. For one,
the runtime needs to parse runtime specific switches which may precede
the switches passed to the user's main program; the runtime specific
switches are removed before calling the user's main program. More
importantly, the runtime's main program creates a shared region in the
address space (using mmap()) and then forks a number of processes
(generally as many as there are parallel processing CPU's), where each
process is effectively a parallel thread of execution beginning at the
user's main program (for various reasons pthreads won't work for this).
Thus, it isn't just the case that the runtime needs
to set up and initialize data - it also changes the control flow in the
program by creating instances of the program which execute in parallel.

Speaking of initialization, I think the Linux 'ld' manpage description
of the --init switch may be wrong for ELF-based systems:

       -init name
           When  creating  an  ELF executable or shared object, call NAME
when
           the executable or shared object is loaded, by  setting  DT_INIT
to
           the  address  of the function.  By default, the linker uses
"_init"
           as the function to call.

I believe that should read "the linker uses "_start" as the function to
call.",
rather than referring to _init()?

> ...
>
> > Alternatively, I would've found it helpful if ld had, in cooperation
> > with glibc() had a method for letting the user substitute their own
> > main entry point, which is called in the conventional fashion, after
> > the C library has initialized. Does such a facility exist in Linux?
>
> Yes, look at the --wrap option to ld.
>

Excellent. Thanks!






reply via email to

[Prev in Thread] Current Thread [Next in Thread]