This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: why no stacktrace?
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: why no stacktrace?
- From: Ulrich Lauther <ulrich dot lauther at mchp dot siemens dot de>
- Date: Thu, 6 Jan 2000 10:18:21 +0100 (MET)
- CC: gcc at gcc dot gnu dot org
- Reply-To: Ulrich dot Lauther at mchp dot siemens dot de
> > I am not a compiler specialist, but isn't the return address on the stack
> > anyway?
>
> Typically, yes. The problem is that you don't know where it is. Consider
>
> void foo(){get_backtrace();}
>
> void bar(int i)
> {
> char c[i]; // C99 VLA
> i = i*2;
> foo();
> }
>
> In this case, location of bar's return address depends on the value of
> the parameter i, which even gets changed. Inside bar, the code
> generated for bar knows how to remove the array from the stack. Nobody
> else does.
>
Thanks for your elaborate explanations and hints for further reading.
But why couldn't a stackframe consist of a fixed part (containing return
address, link to callers frame, and whatever else is needed) and then a
variable part containing parameters or their addresses and local variables.
Wouldn't that be the most natural layout?
[stuff deleted]
> > well, this is how I do it (with limited portability):
> >
> > class stack { // simplified layout of call stack
> > long fudge[PREV_OFF]; // PREV_OFF is platform specific
> > stack* prev; // pointer to stack frame of caller
> > unsigned long ret; // return address
>
>
> That apparently requires that there is a frame pointer on a fixed
> position relative to the return address. That is not universally true,
> eg. with -fomit-frame-pointer on i386.
>
it even rquires a fixed offset between start of a stackframe and position
of the first local variable of a parameterless function; this is how
I get the current stack frame:
void trace_back() {
stack* frame = (stack*) ((&frame) + FRAME_OFF + 1);
}
seems to work sometimes :) on Sparc and ix86.
> to add that, adding overhead. Also, it terribly crashes if you get
> inside a stack frame which does not follow the convention. gdb usually
> gets confused if it sees such a frame.
is't that one more reason to use a simple and universally adhered to
convention? Is it really worth while to optimize parts away?
-ulrich
----------------------------------------------------------------------------
Ulrich Lauther ph: +49 89 636 48834 fx: ... 636 42284
Siemens ZT SE 4 Internet: Ulrich.Lauther@mchp.siemens.de