Re: [cfg-branch]: Outputs dwarf2 location lists using variable tracking info

[Jan Hubicka <jh at suse dot cz>]

Wow, that was fast!

I think cfg-branch is good location for the code until we attempt to push it to
the mainline (hope it will happen soon!), so fell free to commit it there once
you think is it in good shape.  I will try to do the review, but my knowledge
of dwarf is limited.

> I've included a slightly modified version of var-tracking.c, only because 
> I don't have anything to diff it against, stupidly, and I made a few 
> changes (it would record things as changed when they had gone from 1 -> 0 
> locations, recording empty location parts.  It would also crash on memory 
> with no MEM_OFFSET).
> 
> No ChangeLog yet, I just want to post it to get comments.
> To do the dwarf2 location list construction, here's what i've done:
> 
> 1. Added a new debug_hook called var_location to pass the var_locations to 
> the debug writers.
> 2. Call it for each var_location we see in final_scan_insn.
> 3. In the DWARF2 writer, for each var_location we get passed, we do the 
> following:
> 	a. Output a label (since we need it in the right place in the 
> assembly output, we have to do it here, rather than some place later).
> 	b. Throw it on a linked list of locations for the decl it's 
> the location of. If it's not a decl's location [we sometimes have 
> component_refs], we ignore it for now. If it's the same location as the 
> last thing on the list, we just associate the new label with the the last 
> thing in the list, rather than do this later on.
>  4. Later, when we go to add a location attribute to a decl (it's all in 
> two places), we see if we have multiple locations associated with that 
> decl. If so, we create a location list for it.
> The creation of the location list is a bit hair looking.  If you only have 
> one,  you don't want to create one. If you have more than one, we have to 

In case of one location, do we really want to keep it as it is currently?
I mean claim to debugger that the value is valid from first instruction
to the last?  Except argument area all values needs to be initialized first
and they are usually killed in epilogue.  I think it can be valueable to
avoid debugger from printing random noise when possible.

> say it starts at the start label of this location, and ends at the 
> label of the next one. And of course, the last location spans from 
> wherever->the end of the text section.
> We then set the location attribute to the location list, rather than a 
> location expression.
> 5. The actual outputting of location lists that appear in dies was 
> already in place, i did that work earlier. They just never appeared 
> anywhere, so it never outputted them.
> 
> The output is correct, but it shows an interesting problem with the 
> variable tracking:
> It's too fine grained.
> It currently gives us multiple locations whenever it changes, rather than 
> whenever it changes over at least 1 source line.
> If, in one source line, it gets loaded, moved somewhere, some calculation 
> performed, then stored back, we'll end up with > 1 location, even though 
> we don't  really care unless you are doing single instruction stepping and 
> expecting the values to always be right.  It's a pretty high space cost (I 

My plan, about the scope regions as well, has been to introduce function
visible_for_debugger for instruction.  I think the rules should be approximately:

1) each instruction after line number note is visible
2) each may_trap_p is visible
3) each instruction referencing memory that corresponds to variable is visibel
4) volitale references are visible as well
5) named registers are visible (those comming from __asm__)

Jakub was mentioning the possibility of volatile registers, do we support
this concept at all?
Then we can make sure that info is valid for each visible_for_debugger
isntruction.
This is the case of lexical scopes and few other debug stuff as well
(perhaps we can even output unwind information exact only on these
places for the debugger)

> would imagine), since you end up with patterns of alternating "fbreg+16 
> reg3 fbreg+16 reg3 fbreg+16 reg3", with the range of each being one or two 
> instructions.  This is without optimization on. With optimization, you end 
> up with "fbreg+16 reg3 fbreg+16 reg0 fbreg+16 reg2", which still, if 
> occurring in one source line, isn't user visible.

I see, we definitly need to prunning here.

> Should this be handled in the debug writer, just 
> replacing location/merging range until we get to a different source line
> source line ? Or should the variable tracking pass make it's own line 
> easier/not generate as many notes by only considering changes that 
> occur once we see a line note?

I think the variable tracking pass, or the final.c is right place.
While I am not aware of non-dwarf2 format where we plan to support such
generality of debug output, in case we invent some, we want to share
the code.

Thanks!

Honza