Recording of register saves in DWARF2 CFI

Recording of register saves in DWARF2 CFI

[James Molloy]

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.

Thanks very much,

James Molloy

Re: Recording of register saves in DWARF2 CFI

[Andrew Haley]

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?

Andrew.

Re: Recording of register saves in DWARF2 CFI

[James Molloy]

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?
>
> Andrew.
>   
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!

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? (Or, am I interpreting things incorrectly!)

Thanks,

James Molloy

Re: Recording of register saves in DWARF2 CFI

[Andrew Haley]

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.

Re: Recording of register saves in DWARF2 CFI

[James Molloy]

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).

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, why would the 
designers go to this extra length to define a way of retrieving the 
original value of every register? Surely in that case all that would be 
needed is a column for the CFA and a column for the Return Address?

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?

Thanks for your time,

James

Re: Recording of register saves in DWARF2 CFI

[Andrew Haley]

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.