Home > Archive > Unix Programming > July 2004 > stack dump for register based ABI
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
stack dump for register based ABI
|
|
| Alexander Gorshenev 2004-07-28, 9:05 pm |
| What are the most common ways to get stack dump of
a C program on the platforms which use register based ABI
(i.e. most or all the args are passed through registers,
not through the stack. example: opteron).
I think that if compiled for debugging a program could have
a copy of args put in some place on the stack.
But if I compile *not* for debugging this is some overhead
I usually do not expect.
So, is there a way to get stack dump in such case?
| |
| Grant Taylor 2004-07-28, 9:05 pm |
| horsh@mail.ru (Alexander Gorshenev) writes:
> What are the most common ways to get stack dump of a C program on
> the platforms which use register based ABI (i.e. most or all the
> args are passed through registers, not through the stack. example:
> opteron).
> I think that if compiled for debugging a program could have a copy
> of args put in some place on the stack. But if I compile *not* for
> debugging this is some overhead I usually do not expect. So, is
> there a way to get stack dump in such case?
Yes, you walk backwards through the stack, interpreting instructions
as you go to determine where saved registers have been saved.
In the general case this is as painful as it sounds. In specific
cases, there are usually some conventions followed by the compiler
and/or platform abi which make it less awkward.
For example, I wrote mips backtracing code once. There is no stack
frame as such, and the first few function arguments are generally
passed in registers. By convention, there is a stack pointer and
frame pointer register, and there is an architecture-defined return
address register. So you examine instructions leading up to the
current instruction for saved values of ra, sp, fp; thus computing the
values of ra, fp, sp upon function entry; and repeat starting from the
caller's last instruction aka the ra value.
Fortunately, on mips, the instruction set is relatively clean, and gcc
at least doesn't tend to do intermediate shuffling or register
aliasing of the key call chain values, so it's easy to identify the
instruction sequences that save and restore these values.
Actually identifying the sizes and types of function parameters on
mips would require access to debugging information; I would expect
this to be true on most platforms. For that matter, on mips even
identifying the beginning of a function's code while interpreting
backwards for register saves also requires some external data.
On some processors, there are things like register windows and the
like, which may complicate matters significantly. Unless you're using
a new architecture I suggest you find some preexisting backtrace code
to use as a model. For the opteron in particular, if that's what
you're on, there must be several working implementations out there.
--
Grant Taylor
Embedded Linux Consultant
http://www.picante.com/
|
|
|
|
|