[patch] track register arguments in call frame info

[Daniel Jacobowitz]

On Mon, Mar 28, 2005 at 06:36:59PM +0200, Michael Matz wrote:
> Hi,
> 
> the patch below is a forward port of the -fregparam code from the hammer
> branch (originally by Josef Zlomek).  It enables generation of extended
> call frame information to track the location of argument registers on
> dwarf2 platforms.  The constraints for implementing this was: a) no code
> pessimization and b) info not part of debug information.  The reason for
> wanting such a thing is to be able to generate backtraces which contain
> the actual parameters of the called functions.  For parameters passed on
> stack this is trivial as they are not destroyed and are reachable fairly
> easy by looking at some constant offset from the CFA.  For parameters
> passed in registers this is more difficult.  Without code changes saving
> away those values it even is in general impossible.  But still the below
> patch enables the unwinder to track where the initial values of such
> argument registers are placed (by spilling or moving to different
> register) in some cases and as such is usefull for ISVs who wish for as
> precise backtraces as possible under the given constraints.
> 
> This enlarges the .eh_frame section of course, and with real debug
> information this doesn't make that much sense.  Hence it's controlled by a
> flag -fregparam.  It only works on dwarf2 platforms (because the notes
> generated by this pass are only interpreted by dwarf2out.c).  Furthermore
> the effectiveness of all of this (i.e. if backtraces give more information
> without the flag that with it) is only tested on x86-64 (for which it
> initially was implemented).

Interesting.  I assume that what you generate is basically unwind
information for registers which would otherwise be call clobbered, i.e.
the argument registers?

It seems like this new data should be combined with the existing
var-tracking support instead of separate.  That would let GCC generate
DW_AT_location tags for incoming arguments which were actually correct
from the first instruction of the function.  GDB would dearly
appreciate that.

I'm not qualified to say anything useful about the implementation,
though, so that may be completely infeasible...

-- 
Daniel Jacobowitz
CodeSourcery, LLC