[Bug fortran/96158] Debug symbols not emitted for module common variables

[amelvill at umich dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158

--- Comment #11 from AJM <amelvill at umich dot edu> ---
Thanks for all your suggestions, they're very helpful!

>'-falign-commons'
>     By default, 'gfortran' enforces **proper** alignment of all variables
>     in a 'COMMON' block by padding them as needed...

I am not sure what "proper" means in this context, proper for which language,
which architecture? All of them? What's "proper" for AMD64 isn't proper for
i386, and what's proper for Fortran might not be proper for C, right? What
about byte endianness?

> My guess would be that a common block
> is simply considered to be a chunk of memory under
> DWARF5.
> It provides a base address and one needs to
> know how to compute offsets into that chunk (including
> dealing with any padding).

My tests seem to show that this is the case so far too. It seems a bit weird to
me because GCC is able to handle things like individual int "extern" variables
in C, which would seem to have a very similar issue (memory stored in a
different object file, in an ad-hoc manner with no prescribed structure or
packing as an interface).

The only thing that I can think of that's different is the fact that gfortran
generates a .mod file, which I'm guessing (?) is some kind of binary interface
definition (like a precompiled header?); I'm really not sure what it does, but
there is no .mod file generated for "othermodule", only for somemodule (which
matches the file name).

At one point I was just wondering if all I needed to do was generate a .mod
file for othermodule somehow (the common 'module'), but I noticed that the
symbols were stored directly in the .o file, and I started to wonder if the
.mod file served any purpose at all.

>  the Fortran processor (in this case gfortran)
> and its companion C processor (gcc) have the same conventions regarding
> layout of variables etc.

I was hoping this was the case, thanks for confirming that.

> Maybe, if you show the code above to whoever's in charge, that might
> cause that person to reconsider :-)

We've discussed it at great length, these sorts of things have to happen in
stages I think. 

I have informed them of the risks and downsides of not doing this now (I have
been detailed and clear in my findings, including possible portability /
reliability problems and UB problems, additional time spent doing maintenance,
and now also debugging issues). They have decided to accept the risks and
inefficiencies.

Given the circumstances a rewrite is not on the table; the decision is final
and my job now is to support them as best I can. It's hard to allocate limited
resources, there is no lack of work here. That's about all I can say on that I
guess. This is not the first time I have entered a job with a codebase that had
UB, in fact, I would say I have never NOT had a problem with UB at any place
I've ever worked. Personally, I work hard not to introduce more, fix it when I
can, and try and help coders avoid adding more.