From: pavenis AT lanet DOT lv
Message-ID: <B0000110677@stargate.astr.lu.lv>
To: Anton Helm <tony AT dictator DOT nt DOT tuwien DOT ac DOT at>, djgpp AT delorie DOT com
Date: Sat, 27 Nov 1999 13:19:57 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Problems with DJGPP lib and grx23
In-reply-to: <4.2.0.58.19991126181032.00a65c40@hal.nt.tuwien.ac.at>
References: <199911241840 DOT TAA05908 AT acp3bf DOT physik DOT rwth-aachen DOT de>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 26 Nov 99, at 18:35, Anton Helm wrote:

> At 07:40 PM 11/24/99 +0100, you wrote:
>  >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:
>  >> Main problem with debugging is that this is a graphic application
>  >> and the problem is related to displaying a mouse cursor.
> 
>  >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.
> 
> 1) extracted the shiftscn.o from the 2.8.1 compiled library 
>     and replaced it with the 2.95 compiled version. 
>     -> crash (as expected)
> 2) replaced  shiftscn.o in the 2.95 compiled library with 
>     the one extracted from the 2.8.1 compiled library.
>     -> now the new library works (as expected)
> 

Perhaps src/utils/shiftscl.c but not shiftscn.c

> disassembled the 2.8.1 compiled objectfile and tried to compare
> it with the assembly code of the 2.95 compiled file.
> 
> Well, if you know what you are looking for, you probably find it. I don't.
> Program crashes at _GR_shift_scanline+99 while running the first inline asm part.
> This is somewhat mysterious as 99 is definitely out of this inline asm part.
> (See the second asm file attached below.)
> So the bug is probably related to embedding the inline asm into the rest.
> 
>  >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.

Verified that _GR_shift_scanline works for me compiled with gcc-
2.95.2 (tested it's really called). However I have patched GRX-2.3 rather
much (some patches from me, also ones from other authors)

I also used gcc-2.95 and gcc-2.95.1 earlier and didn't met problems 
except than I had to fix invalid inline assembler instructions to appease
gcc-2.95 and also some assembler instructions operands needed to use
rather recent binutils snapshots.

> 
> I have no 2nd video card.
> I've tried fsdb and got a crash (of fsdb) when the program switched 
> into graphic mode. So that doesn't help much.
> 
> Back to gdb ...
> gdb (4.18) tells me (by stepi) that it is running the first inline asm part when
> the crash happens (SIGSEGV).
> 
> Here are asm files, first the 2.8.1 compiled :
> 
> shiftscl.o:     file format coff-go32
> 
> Disassembly of section .text:
> 
> 00000000 <__GR_shift_scanline>:
>     0:	83 ec 0c       	subl   $0xc,%esp
>     3:	55             	pushl  %ebp

assembler output skipped.

> 
> Sorry for this huge mail.
> 

Perhaps it would be better to post small example which causes crash
in _GR_move_scanline() when latest is compiled with gcc-2.95.X.

Andris