Mail Archives: djgpp/2001/06/25/22:15:04
On Mon, 25 Jun 2001 15:56:03 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>You should be safe all the way until you hit the stack bottom, i.e. use
>up all the 512KB of the default stack.
That's a lot. The worst-case recursion in the program would, however,
recurse over every pixel on a 1024x768 display, easily exceeding that.
OTOH, the worst case shouldn't happen except for seriously
pathological cases. Indeed, the only pathological case I can conceive
of has it land at very high magnification in the middle of a
Mandelbrot component or far from the Set, then try to distance
estimate and tile with recursive disks, but if it's past the precision
limit, the disk radii it sees should be zero, which tells it to plot
white pixels iteratively instead of tile black disks recursively, so
it Can't Happen (tm). Nonetheless I'll add code to check for this
case. (Anyway, I've since developed a hybrid algorithm that is purely
iterative and, moreover, faster.)
>You can go as far as 1KB, I think. Unless a single invocation uses up
>more than 1K of stack space, that is.
I tend to err far on the side of caution with these things. If it uses
498k of stack something's gone just as wrong as if it uses 511k.
>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. If stack smashage is suspected, the
programmer can just use -g and disable -fomit-frame-pointer. (They'll
likely do this anyway, to get more than just the most recent function
in their stack trace, at least if all they learned the first go-around
was that it died in printf() called from the line of the beast, or
some other library function that is called in multiple functions or in
a recursive one.) Then they get a nice report of exactly when their
program smashed the stack. When it's debugged, they can turn the
optimization back on for making the production code.
>> How can the tables get damaged? For a wild pointer to run into the
>> exception tables, it has to run out of its normal bounds, and cause a
>> SIGSEGV, doesn't it?
>
>The tables are part of the application's data segment, so no level of
>protection can prevent the application from overwriting them.
>
>DPMI limitations don't allow to use a different segment for those tables,
>since the only register that is guaranteed to be valid when you enter an
>exception handler is CS. So at least some crucial data needed for
>exception handling _must_ be accessible via CS. That is why CS and DS in
>the DJGPP run-time environment share the same memory region.
You can't change DPMI, but you can extend it when CWSDPMI is used. It
is well worth considering it. As above, when a programmer encounters a
problem the usual methods aren't solving, they can do something
special: in this case, drop to pure DOS and use CWSDPMI.
>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. If an exception is raised, the program notes
that it is running under CWSDPMI. Regardless, after the attempted
read, it then puts the usual SIGSEGV handler in place and continues.
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -