This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gcc-4.5-20090528 is now available
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: Angelo Graziosi <angelo dot graziosi at alice dot it>, Fortran <fortran at gcc dot gnu dot org>
- Date: Sat, 30 May 2009 16:05:42 +0100
- Subject: Re: gcc-4.5-20090528 is now available
- References: <4A20F778.9010705@alice.it> <4A214191.1050206@gmail.com> <4A2143EA.2050904@gmail.com>
Dave Korn wrote:
> A breakpoint set on *__gfortrani_init_variables is indeed not hit.
> static void __attribute__((constructor))
> init (void)
> So looks like we have a .ctors problem. I'll start rummaging through
> libgfortran.a and take a look at the final link etc.
The main.o object is pulled in from libgfortran.a ok, it has the correct
.ctor/.dtor data, and the executable has a fully-formed __CTOR_LIST__. The
problem is that libgfortran's runtime doesn't call Cygwin's __main function
which is responsible for running the ctors at startup. The C compiler
magically inserts such a call at the start of the C main function, and if I
breakpoint at the start of the fortran main function and call __main from the
debugger, the options get initialised and the program then runs correctly:
------------------------------------------------------------
$ gdb ./hello.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
This GDB was configured as "i686-pc-cygwin"...
(gdb) b main
Breakpoint 1 at 0x401153: file hello.F95, line 6.
(gdb) r
Starting program: /tmp/fortran/hello.exe
[New thread 1892.0x594]
[New thread 1892.0x850]
Breakpoint 1, main (argc=1, argv=0x10079ea8 '/tmp/fortran/hello\000')
at hello.F95:6
6 end program hello
Current language: auto; currently fortran
(gdb) call __main()
(gdb) c
Continuing.
Hello World!
Program exited normally.
(gdb)
------------------------------------------------------------
According to the internals manual:
------------------------------------------------------------
http://gcc.gnu.org/onlinedocs/gccint/Initialization.html
If no init section is available, when GCC compiles any function called
`main' (or more accurately, any function designated as a program entry
point by the language front end calling `expand_main_function'), it
inserts a procedure call to `__main' as the first executable code after
the function prologue. The `__main' function is defined in `libgcc2.c'
and runs the global constructors.
------------------------------------------------------------
and this is controlled from gimple_expand_cfg() in cfgexpand.c, where it tests:
/* If this function is `main', emit a call to `__main'
to run global initializers, etc. */
if (DECL_NAME (current_function_decl)
&& MAIN_NAME_P (DECL_NAME (current_function_decl))
&& DECL_FILE_SCOPE_P (current_function_decl))
expand_main_function ();
which comes from (reformatted):
tree.h:#define MAIN_NAME_P(NODE) \
(IDENTIFIER_NODE_CHECK (NODE) == main_identifier_node)
which is defined here:
c-common.c: main_identifier_node = get_identifier ("main");
So. No language except the C family gets .ctors run automatically unless it
sets up main_identifier_node. Ada has some code to to it in
ada/gcc-interface/trans.c, but gfortran appears to have missed it out.
This is now PR40309. Looks almost trivially easy to fix for anyone familiar
with the structure of the fortran frontend.
cheers,
DaveK
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309