Bug 29548 - VERY BAD: gdb does not work with gcc-g77 as shipped with RH7 fisher and wolverine with static variables
Summary: VERY BAD: gdb does not work with gcc-g77 as shipped with RH7 fisher and wolve...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-26 14:42 UTC by Alfredo Ferrari
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-26 23:06:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
various files/scripts demonstrating the bug (106.08 KB, text/plain)
2001-02-26 14:44 UTC, Alfredo Ferrari
no flags Details

Description Alfredo Ferrari 2001-02-26 14:42:20 UTC
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
results in
 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 variables).
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.

Reproducible: Always
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

Comment 1 Alfredo Ferrari 2001-02-26 14:44:24 UTC
Created attachment 11123 [details]
various files/scripts demonstrating the bug

Comment 2 Jakub Jelinek 2001-02-26 23:06:32 UTC
Should be fixed by:
2000-09-22  Jason Merrill  <jason@redhat.com>

        * dbxout.c (dbxout_symbol_name): Just use DECL_NAME for
        function-local names.
which I've just added to my patch queue.

Comment 3 Jakub Jelinek 2001-03-07 11:10:34 UTC
Fixed in gcc-2.96-77.1.

Note You need to log in before you can comment on or make changes to this bug.