Re: Recording of register saves in DWARF2 CFI

[Andrew Haley <aph at redhat dot com>]

James Molloy wrote:
> Andrew Haley wrote:
>> James Molloy wrote:
>>  
>>> Andrew Haley wrote:
>>>    
>>>> James Molloy wrote:
>>>>  
>>>>      
>>>>> Hi,
>>>>>
>>>>> I'm attempting to write a cross-platform debugger for a hobby kernel,
>>>>> and as part of which I use DWARF-2's CFI stack unwinding
>>>>> functionality.
>>>>>
>>>>> This works perfectly, however I would also like to obtain the
>>>>> parameters
>>>>> given to each function call on the stack. I can do this easily in
>>>>> x86 as
>>>>> all the parameters are passed via stack, however on x64 and MIPS I'm
>>>>> having difficulty, as the first X parameters are passed via register.
>>>>>
>>>>> The DWARF-2 specification makes allowance for this - the CFI system is
>>>>> capable of determining the value of any and every register at the
>>>>> start
>>>>> of any stack frame - but I have noticed that GCC doesn't record
>>>>> unwinding rules for many registers (seemingly any register not
>>>>> essential
>>>>> to the finding of the CFA or return address).
>>>>>
>>>>> Is there any flag available to enable recording of every register, or,
>>>>> even better, certain registers, for every stack frame? I've grepped
>>>>> the
>>>>> manual to no avail.
>>>>>         
>>>> Surely this is in the debuginfo, not the unwinder data.  Aren't
>>>> you looking in the wrong place?
>>>>       
>>
>>  
>>> Although it is indeed possible to pull this information out of the
>>> debuginfo, the debuginfo section is *massive* and gives far more
>>> information than I need or want - it describes the entire low level
>>> structure of the program - all I want is to be able to find where
>>> parameters are!
>>>     
>>
>> So what is the problem with using the debuginfo in a debugger?
>>  
>>> The .debug_frames section is far smaller by comparison and seeing as I
>>> already use it for stack unwinding I felt that using it along with an
>>> idea of the default ABI for a given architecture would provide a useful
>>> and compact way of determining function parameters and helping my
>>> developers.
>>>
>>> The DWARF definition version 3.0 section 6.4 describes editing
>>> "activations" - this section seems to imply that the full register set
>>> should be available for editing for any unwound stack frame - not just
>>> select registers.
>>>
>>> Has this been implemented in GCC? Or was there an assumption that most
>>> debuggers would use the .debug_info information anyway so it was
>>> redundant?
>>>     
>>
>> Well, yes.  The unwinder data contains what you need for unwinding; the
>> debug data contains what you need for debugging.
>>
>> It's important to realize that the unwinder data is as small as possible,
>> containing only what's needed to unwind the stack. 
>> Andrew.
>>   
> Hi,
> 
> I've just been pondering this over lunch and have a couple more queries,
> if it's ok to take up some more of all your time!
> 
> At the very start of section 6.4, where the DWARF 3.0 specification
> defines "Call frame information", I quote, truncated:
> 
>> Debuggers often need to be able to view and modify the state of any
> subroutine
>> activation that is on the call stack. An activation consists of:
>>  * A code location within the subroutine [...]
>>  * An area of memory allocated on a stack called a "call frame" [...]
>>  * A set of registers that are in use by the subroutine at the code
> location.
> 
> It is the last bullet point which interests me. It implies that when
> unwinding the stack with dwarf's CFI method, All registers in use in an
> activation should be returned to their state when that activation was
> left (i.e. left by a CALL or JAL).

Right.  We do that.

> Not only that, but the CFI structure is defined as an extremely large
> table with each row being a PC location and having columns consisting of
> a CFA column, a return address column, and a column for each register.

> If what you say is true, and the unwind information was only designed to
> deal with finding base addresses and return addresses, 

I didn't say that.  I said the unwind info only contains what's needed
to do the unwinding.

> why would the
> designers go to this extra length to define a way of retrieving the
> original value of every register? 

We output unwinder data for every register that must be restored when
throwing an exception.  This isn't every register: some will be marked
by the ABI as call-clobbered so we don't need to restore them and we
don't therefore need to emit any unwinder data for them.

> Surely in that case all that would be
> needed is a column for the CFA and a column for the Return Address?

I didn't say that DWARF data was only intended to do unwinding: I said
that the unwinder data gcc emits is only for that.

> Also, the CFI example in appendix D6 clearly shows information to
> retrieve register values being saved for registers which do not
> contribute to the calculation of the CFA or the return address (see
> Figure 62, speccifically the R4 column).
> 
> Am I still barking up the wrong tree here?

Not at all.  It's important to realize that DWARF data can represent
far more than we choose to emit in gcc.  All that we claim is what we
emit conforms to DWARF, not that we emit everything that DWARF makes
possible.

Andrew.