Third segmentation fault in GDB 4.17 and comments on previous patch

Craig Burley
Thu Jul 2 08:04:00 GMT 1998

>I have the impression that GDB really needs someone for F77 support and
>that the GDB project needs better communication with the G77 project.

I think the ball has been fairly clearly in g77's court for some time
now, as should be evident to anyone reading the g77 docs or g77.plan
file, which explain the known deficiencies and such.  We g77 folks
haven't exactly been sitting around waiting for gdb to just "get
better"; and we've been too busy just getting g77 to work right to
really set aside the resources we think it'll take to fix g77's
debugging problems.

Until we can finally make time to look into these issues more
seriously, I think it would be wise for gdb developers to
restrict their efforts vis-a-vis Fortran to making gdb work
properly/elegantly/cleanly with *other* appropriate Fortran
compilers, rather than g77 (or f2c, of course).

In particular, it's probably counterproductive to work around
cases where g77 emits the wrong info, or at least misleading info.

I have high hopes that g77 will be actively improved in this
area sometime in this calendar year, but of course can't
make promises (without funding).

>> Perhaps g77 should output the type of __g77_length_* as `integer*4', to
>> avoid an `Invalid type code' message from GDB, but I don't know.
>That is probably true but I am not involved in the g77 development and perhaps
>the g77 developers should comment on that point.

The length of a dummy-arg string is actually type `ftnlen' as
defined by the f2c.h file for a g77 build, which gets into
pretty complicated areas.

But, usually, this is equivalent to whatever `integer*4' is anyway,
so perhaps g77 could make a special case here: if the type is the
same, output `integer*4' instead of `ftnlen', which is what I assume
is being output currently (?).

But, would this look strange to someone debugging code and seeing
the type as evidently different in one routine from another,
e.g. when a Fortran routine that sees it as `integer*4' passes
it to a libf2c routine like s_copy that sees it as `ftnlen'?  I
think g77 tries to be "faithful" to the high-level types as a rule, to
avoid confusion in areas like this.

>Perhaps g77 should (in future) better emit the right debugging information.

Hallelujah and amen, brother!

>I cannot imagine that INT_MAX (because type->fields[...].loc.bitpos is 'int')
>would be a good size of an array in any language).

g77 has a history of doing strange things to support stuff like
assumed-size arrays.  (These are kind of like `int *c[];' declaring
a dummy arg in C, in that no overt high bound on the size of the
array pointed to by `c'.)

Since g77 needs to support arbitrary low bounds, and the gcc back end
requires either no bounds (no build_range_type call when making
the type) or both low and high bounds, g77 had to stuff something
into the high bound.

Long ago, it stuffed a copy of the low bound, which got the job
done, but was asking for trouble when other parts of g77 started
trying to figure out when avoiding making extra copies through
temporary variables on function calls was possible.

So, for several releases (including, IIRC, the current official,
non-egcs version, 0.5.23), g77 switched to stuffing INT_MAX (or
whatever the largest value was for the pertinent range type)
in as the high bound, so it would be sure not to, elsewhere,
think that a reference to the array couldn't be to an element
above the low bound (and thus emit code with overlap/alias bugs).

This ran into trouble with smarter gcc compiler diagnostics, especially
those in egcs, and, while the problem might really have been in g77
anyway (and was fixed later), the egcs developers caught wind of
this little annoyance and decided to fix the gcc back end to support
a NULL_TREE for the high bound throughout (which is what g77 wanted
in the first place).

So the egcs (as of which version, I forget) version of g77 stuffs
NULL_TREE into the high bound of the range type it builds for
the final dimension of an assumed-size array.

For CHARACTER*(*), this issue doesn't apply to the length (though,
of course, it might still for an assumed-size CHARACTER*(*) array).

In that case, g77 tells the back end that the high bound is
determined by the incoming __g77_length_FOO argument.

However, this has also changed recently so that the back end sees
this as a SAVE_EXPR instead of just a PARM_DECL (IIRC).  The
PARM_DECL approach, aka direct assignment, seemed okay because
g77 "knows" the variable never gets (legitimately) modified.

But this crashed the compiler on Irix (?) or whatever systems use
dwarf2out.c (IIRC), and it just seemed wise to change this one
place to pass the length through the variable_size() call in
the back end as happens everyplace else g77 builds an adjustable
array (which is what CHARACTER*(*) amounts to, except with
user-defined adjustable arrays, the user specifies the bounds
expressions explicitly, and also the pertinent info on the
variables contained within those expressions, all of which is
automatically done, behind the scenes, for CHARACTER*(*)).

I think that particular fix went into g77 0.5.23, and should be
in egcs snapshots, but probably not egcs 1.0.3a.

Hope this helps.  Any "obvious" things g77 can do to help ease
the debugging problems, email them to <> or,
especially if egcs-gcc back-end issues are involved (certainly
the case with the gaping holes in g77's support for debugging
COMMON/EQUIVALENCE), <>.  We'll see what we can do.

And, in case it is't obvious from the above, I don't think there's
any problem with, if appropriate, making incompatible changes
in g77 so that users have to upgrade and recompile to use a
new gdb, etc.

But that's not so good for gdb, which is why I suggest avoiding
changing gdb in any ways that might be regretted down the road.  g77
is still officially in "beta test", but I don't think gdb is.

        tq vm, (burley)

More information about the Gdb mailing list