This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>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 <fortran@gnu.org> 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), <egcs@cygnus.com>. 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)