Re: Question about LTO dwarf reader vs. artificial variables and formal arguments

[Daniel Jacobowitz <drow at false dot org>]

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