On Sat, Oct 21, 2006 at 06:35:40PM +0200, Steven Bosscher wrote:
> where _c is strlen("Hi World!"). From a user perspective, it would be better
> to hide _c for the debugger because it is not something that the user had in
> the original program. I have a patch to hide that parameter, that is, it
> stops GCC from writing out DW_TAG_formal_parameter for _c. But I am worried
> about how this will work out later if/when someone tries to make LTO work for
> gfortran too.
> Can you still reconstruct the correct function prototype for LTO from the
> debug info if you don't write debug info for _c?
Wouldn't this be upsetting to debuggers, too - for instance, if they
wanted to call the function? It might be wiser to tag it
DW_AT_artificial, and let the debugger sort out what to do with it.
> Similarly, LTO has to somehow deal with DECL_VALUE_EXPR and the debug
> information that is produced from it. Gfortran (and iiuc other front ends
> and SRA) use this DECL_VALUE_EXPR to produce fake variables that point to
> some location to improve the debug experience of the user. For Fortran we
> use it to create fake variables to point at members of a COMMON block, for
> example, so that the user can do "p A" for a variable A in a common block,
> instead of "p name_of_the_common_block.A". Is there already some provision
> to handle this kind of trickery in LTO?
I don't think we're far enough on yet to know the answer to this or
your other question, but I may be wrong. There's a reason we're
focusing on C right now :-) I don't think the design precludes this
sort of thing, but we won't know how it all fits together until more's
been done.
--
Daniel Jacobowitz
CodeSourcery
