This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc-4.5-20090528 is now available


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]