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
