Date: Fri, 28 Apr 1995 05:24:26 -0300 (ADT)
From: Bill Davidson <bdavidson AT ra DOT isisnet DOT com>
Subject: Re: Chaining real-mode interrupts
To: Mat Hostetter <mat AT ardi DOT com>
Cc: dgymer AT gdcarc DOT co DOT uk, djgpp AT sun DOT soe DOT clarkson DOT edu



On Thu, 27 Apr 1995, Mat Hostetter wrote:

> If you think gcc's assembly output is wrong, post it!  I've responded
> to a zillion messages where people have complained of a possible gcc
> problem but never provided enough information.

This brings up an interesting point.  A while ago I mentioned some 
strange behaviour relating to dereferencing a pointer before it was 
assigned to (with optimization enabled; everything was OK without 
optimization).  You (I think) quite rightly suggested that I post the 
offending code as output by gcc -S.  I ran gcc -S on the file involved 
(with and without -O and -O2); the assembler output was as it should have 
been.  But, _I know what I saw_!  The program was segfaulting on a NULL 
pointer reference, 'symify' pointed me at the offending line of code, and 
I ran a debugger with a breakpoint on the offending function.  That's 
when I saw the program skip the assignment and dereference the pointer.  
I keep wondering whether the output provided by -S and the output 
actually submitted to the assembler might be at all disjoint.

> I've forgotten the original thread, but basically V1.x has massive
> problems with interrupts. 

No shit!

> I have spent many, many hours dealing with
> V1.x interrupt problems, and eventually we (ARDI) wrote our own
> interrupt handling stubs in assembly to set up the stack, etc.

OK, I'm just a piker trying to use the available high-level functions to 
do this, but it's not working as it should.  I eventually recompiled the 
module containing the interrupt routines without optimization, and things 
were better, good enough to use a debugger instead of the machine hanging 
or rebooting as soon as an interrupt vector was changed (real mode).
Then I started tracing into my code (all other modules compiled with 
-O2).  Now, I know that optimization can fool a debugger, but here's what 
happened.  I got to where main() calls a certain function 
(CreateWindow()), stepped into the function, traced through it until it 
returned, but I wasn't back in main(), I hit four more ret's before I got 
back to main() (with some intervening code).  I know I should have done 
the experiment again, dumping stack contents to see where I should 
return, but I got fed up and recompiled the whole program (library, 
actually) without optimization, and the result was _much_ more stable.  
Still a few odd mouse-related problems, but I think that's fixable.

> Fortunately, interrupts appear to be rock-solid under djgpp V2 if you
> follow the rules (lock down all memory touched at interrupt time,
> remember that %ss != %ds during interrupt time, etc.)

Great!  So when will it be released?  I generally have an aversion to 
alpha and beta products (in fact, any x.0) but I am going nuts trying to 
get a program that will compile and run under Turbo C to work under gcc!

Bill