Red Hat Bugzilla – Bug 29548
VERY BAD: gdb does not work with gcc-g77 as shipped with RH7 fisher and wolverine with static variables
Last modified: 2007-04-18 12:31:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-3smp i686)
On RH7 with all updates installed, fisher and wolverine, there is an
incompatibility of some kind between g77 and gdb. Apparently all local
variables flagged with a SAVE statement (-> made static) or ALL VARIABLES
in case the -fno-automatic option is used (which makes static all local
variables) are invisible to the debugger. Every attempt to look at them
No symbol "..." in current context.
Everything worked nice under RH6.2. Of course debugging of programs is
practically impossible, taking also into account that for historical
reasons (all compilers were SAVing everything till a few years ago) many of
them need to be compiled with -fno-automatic.
I attach a small tar file with the same few line long code, compiled
without -fno-automatic and ran into a crash (dobug1), compiled with
-fno-automatic and crashed and slightly changed SAVing the variables and
crashed. There is also a small c code to set on exception trapping. The
latter two cases result in the wrong behaviour (gdb being unable to access
The script dobugs does the whole job.
Of course we hit the bug on much larger codes.
Needless to say the problem is serious. Now that apparently most of the
striking bugs of fortran support in RH7 are apparently solved, we are
stopped again because of debugger issues. I selected the compiler as the
faulty component but of course it could be the debugger as well or the
linker in case it flags in some funny way those variables.
I stress again that this is common to RH7, fisher and wolverine.
A comment I cannot refrain from for the quality assurance guys: I followed
all polemics on the RedHat lists about the compiler shipped with RH7 (and
fisher and wolverine). I read the claims from the RedHat guys that is was
thoroughly tested etc, among the others by compiling with it the whole
distribution. However it is crystal clear that no test at all has been done
with fortran (maybe compiling "hello world"), and that shipping a buggy and
untested snapshot of the compiler for fortran users and developers (which
are quite a large fraction of the scientific community) resulted in a major
The compiler had major problems itself, unwise changes in the
compiler/linker interaction resulted in further problems, the debugger does
not work with the compiler, nice! After more than six months from its
release RH7 and following are still poor alpha releases for what concern
scientific calculations with fortran. Maybe a regular release of the
compiler with all feedback from users it usually comes with would have been
a wiser solution. I know there were good reasons
to ship this snapshot instead, however RedHat should have taken all
necessary steps to fix it in this case.Here at CERN most guys made the
equation RH7=crap and indeed the Lab
Computer Division discourages its use. I believe to be among the few ones
who are trying to get usable (even though I do it on my test system only
and all production machines on the group I am responsible for are still on
6.2), however it starts to be quite a discouraging task.
Steps to Reproduce:
1.compile a fortran code with -fno-automatic or with SAVEd variables in a
2.run it in such a way to make it dump core
3.run gdb trying to access whichever SAVEd variable
Actual Results: I cannot access any local variable in the debugger
Expected Results: The debugger should be able to access local variables at
it was able to do till 6.2
Created attachment 11123 [details]
various files/scripts demonstrating the bug
Should be fixed by:
2000-09-22 Jason Merrill <email@example.com>
* dbxout.c (dbxout_symbol_name): Just use DECL_NAME for
which I've just added to my patch queue.
Fixed in gcc-2.96-77.1.