This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: why no stacktrace?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]