Mail Archives: djgpp/2001/06/28/14:05:55
On Tue, 26 Jun 2001 21:25:02 +0100, Richard Dawe
<rich AT phekda DOT freeserve DOT co DOT uk> sat on a tribble, which squeaked:
>Hello.
>
>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. If stack smashage is suspected, the
>> programmer can just use -g and disable -fomit-frame-pointer.
>[snip]
>> When it's debugged, they can turn the optimization back on for making
>> the production code.
>
>So you want different behaviour when compiled with -g and without?
Of course not. Not in the sense of changing the semantics of a correct
program. But the semantics of an incorrect program are undefined
anyway, and plenty of Scroedinbugs disappear when the debugger is used
anyway. Here I'm looking for the use of debugging to actually make the
bugs easier to detect, which sure seems sensible given that we are,
after all, talking about debugging.
>Have you tried putting a limit on the recursion in your program, to see
>whether that stops the stack overflow? Maybe that would at least help you
>debug?
I haven't gotten around to it yet: I've been too busy with Usenet
lately. It seems every time I log on there's a zillion followups to my
postings, and most of them demand some kind of a response...
--
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 -