Mail Archives: djgpp/1999/11/24/14:35:20
In article <4 DOT 2 DOT 0 DOT 58 DOT 19991124161000 DOT 00a11cb0 AT hal DOT nt DOT tuwien DOT ac DOT at> you wrote:
> At 01:00 PM 11/24/99 +0100, you wrote:
> >You (or someone) will have to dig a bit deeper: generate the crash
> >inside a gdb session or write down the exact address found in the
[...]
> Main problem with debugging is that this is a graphic application
> and the problem is related to displaying a mouse cursor.
Well, first thing to do, then, would be to reduce the code size of the
example case, to the point where it is not reducible any further
without removing the bug, together with it...
E.g.: what happens if you use just that one .o module containing the
problematic assembly function from the existing, known-working 2.8.1
compilation of GRX, and all the rest from the 2.95 one. Just to make
sure it's really *this* function that actually causes the problem,
that is.
Comparison of the actual assembly code produced by versions 2.95 and
2.8.1 would also probably help to isolate the problem. And it could be
done 100% outside graphics mode. Seeing 'gcc -S' output for the
current compiler, and an 'objdump -dx' for the 2.8.1 generated object
file, I might be able to see the problem. So might some others in this
newsgroup.
> I am no gdb guru either but to my experience it isn't that easy to
> debug such programs with gdb. (At least I always managed to avoid it.)
It's hard, but manageable, if you have some 'trick hardware': you need
a secondary mono graphics card (a 'Hercules card', something which
went out of fashion at least 8 years ago :-) and a second, monochrome
screen attached to it, so you can run gdb on the mono screen, and the
graphical program on the other. If gdb doesn't want to work in that
configuration, try rhgdb, fsdb or, last chance, edebug32, the mother
of all DJGPP debuggers.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -