Mail Archives: djgpp/1995/04/28/14:23:35
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
- Raw text -