Mail Archives: djgpp/2001/06/26/09:10:50
On Tue, 26 Jun 2001, Graaagh the Mighty wrote:
> >That would require to use a separate selector for the stack (because the
> >stack is expand-down, and so needs a special segment setup for detecting
> >stack overflows). This is possible, but has a serious problem: you
> >cannot use -fomit-stack-pointer, because the EBP register will trigger a
> >GPF if loaded with a value larger than the stack size.
>
> That suggests to make such a scheme be used when code is compiled with
> -g and not -fomit-frame-pointer.
The problem is, -fomit-frame-pointer is a compiler switch, while the
setup of the runtime environment is done in the library. How will the
library startup code know that -fomit-frame-pointer was used or not?
In any case, forcing the programmer to change compilation switches to
debug is a Bad Idea (tm): one more general-purpose register makes a
world of difference on x86, so you are essentially debugging a
different program. It's quite likely that elusive bugs will either
disappear or change their behavior, and the backtrace will not be
useful.
In any case, the current setup is based on lots of experience and hard
work by many people, so you can safely assume that any reasonable
alternative was already examined and found to be worse.
> >I was talking about the code that gets linked into your program, not
> >about CWSDPMI. The code in your program doesn't know what host it will
> >run with, so it needs to work with all of them, which means playing by
> >the rules.
>
> Unless it has some way of identifying the host. Which it does. The
> startup code can simply attempt to read from 0; CWSDPMI will trap this
> while Windoze will not.
There are other DPMI hosts that support this feature. So
identification is not so simple.
- Raw text -