14.1.6 Ease of Debugging

Because g77 compiles directly to assembler code like gcc, instead of translating to an intermediate language (C) as does f2c, support for debugging can be better for g77 than f2c.

However, although g77 might be somewhat more “native” in terms of debugging support than f2c plus gcc, there still are a lot of things “not quite right”. Many of the important ones should be resolved in the near future.

For example, g77 doesn't have to worry about reserved names like f2c does. Given `FOR = WHILE', f2c must necessarily translate this to something other than `for = while;', because C reserves those words.

However, g77 does still uses things like an extra level of indirection for ENTRY-laden procedures—in this case, because the back end doesn't yet support multiple entry points.

Another example is that, given

     COMMON A, B
     EQUIVALENCE (B, C)

the g77 user should be able to access the variables directly, by name, without having to traverse C-like structures and unions, while f2c is unlikely to ever offer this ability (due to limitations in the C language).

Yet another example is arrays. g77 represents them to the debugger using the same “dimensionality” as in the source code, while f2c must necessarily convert them all to one-dimensional arrays to fit into the confines of the C language. However, the level of support offered by debuggers for interactive Fortran-style access to arrays as compiled by g77 can vary widely. In some cases, it can actually be an advantage that f2c converts everything to widely supported C semantics.

In fairness, g77 could do many of the things f2c does to get things working at least as well as f2c—for now, the developers prefer making g77 work the way they think it is supposed to, and finding help improving the other products (the back end of gcc; gdb; and so on) to get things working properly.