Re: why no stacktrace?

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

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

That is the typical layout, indeed. It's just that the fixed part does
not necessarily have a pointer to the previous stackframe, and that
there might not be any mechanism to find out the size of the variable
part.

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

The question is not whether it is worth changing it, the question is
whether it is feasible to change it. If it is changed now, it would
take years to propagate even throughout the world maintained by gcc;
other compiler vendors might never change their ABI appropriately.

Even for gcc, there will be a significant opposition, saying that they
would accept such a function as optional, and reject it if it is
mandated. However, that is exactly the status quo.

Because of the little advantages gained, and the serious problems
expected (both technical and political), it is unlikely that an
individual would ever undertake an effort to change the status quo.

Regards,
Martin