Steven Bosscher wrote:
I want to make gfortran produce better debug information, but I want to do it
in a way that doesn't make it hard/impossible to read back in sufficient
information for LTO to work for gfortran.
I haven't really been following the whole LTO thing much, but if I understand
correctly, the goal is to reconstruct information about declarations from
DWARF information that we write out for those declarations. If that's the
case, I wonder how LTO will handle artificial "variables" and formal argument
lists.
[much snippage]
The short answer is that I don't know the answer to your questions. ;-) So far
I've been focusing on C in the LTO reader, with a few hooks for C++, and I'm not
familiar enough with the Fortran front end to know what special challenges it
might present.
If your goal is to produce better debug information, I'd just focus on doing
that within the constraints of Dwarf, and forget about LTO entirely. For
instance, I agree with the suggestion that the Fortran front end ought to be
tagging artificial variables with DW_AT_artificial instead of resorting to other
hacks. That's about keeping the debugger happy and really has nothing to do
with LTO.
If Dwarf just isn't adequate to represent the full Fortran type information in a
way that allows it to be fully reconstructed by the LTO front end, we can both
extend Dwarf and extend the Gimple dumper, e.g., by dumping both the "real type"
as well as the "declared type" you want the debugger to see. Or we might end up
not using Dwarf at all in the long run.
-Sandra
