www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/11/24/07:45:21

Date: Wed, 24 Nov 1999 13:00:32 +0100
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id: <199911241200.NAA05607@acp3bf.physik.rwth-aachen.de>
To: djgpp AT delorie DOT com
Subject: Re: Problems with DJGPP lib and grx23
Newsgroups: comp.os.msdos.djgpp
Organization: RWTH Aachen, III. physikalisches Institut B
X-Newsreader: TIN [version 1.2 PL2]
Reply-To: djgpp AT delorie DOT com

In article <4 DOT 2 DOT 0 DOT 58 DOT 19991124101342 DOT 00a654d0 AT hal DOT nt DOT tuwien DOT ac DOT at> you wrote:
> At 09:28 AM 11/23/99 -0800, you wrote:
[...]

> GCC 2.95 complains in both asm sections about the use of "cx" in the
> last line.  As far as I understand this is some kind of dummy
> register.

Not really. The last line mentions 'cx' as 'clobbered' ... the value
that might have been in it, is changed by the asm fragment. At the
same time, the ecx (cx?)  register is specified as an input operand,
by the '"c" ((int) shift' part in the second line of the fragments
shown below. This practice of naming the same register as an output
and a spilled register is what gcc-2.95 objects to.

> The patches mentioned earlier here in this mailing list/newsgroup change the
> last three lines of both sections from

>      	  : "=r" ((void *)s), "=r" ((void *)d), "=r" ((int)w)
>      	  : "0" ((void *)s), "1" ((void *)d), "2" ((int)w), "c" ((int)shift)
>      	  : "ax", "cx"

> into

>          : "=r" ((void *)s), "=r" ((void *)d), "=r" ((int)w), "=cx" (dummy)
>          : "0" ((void *)s), "1" ((void *)d), "2" ((int)w), "c" ((int)shift)
>          : "ax"

[...]
> Digging
> somewhat deeper with gdb let me suspect that there might be something wrong 
> with the "jmp 1f" statement but that's only a guess. 

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
coredump (i.e. traceback). Then *disassemble* the above routine, and
find out what instruction is causing the problems.  Print register
contents. Try to deduce what's happening.

Or, (simpler, IMHO): follow the execution of that routine in the
full-screen debugger, 'fsdb'. For low-level stuff like this, I
routinely would use fsdb, instead of gdb: it works on assembly level,
mainly, and you get to see the machine code, along with all register
contents, as you step through it.

> There is a precompiled (GCC 2.8.1)library available from 
> http://www.gnu.de/software/GRX/download/
> which is said to be compiled from the original code quoted above. This binary
> doesn't produce runtime errors when calling the same function.

Disassemble both versions of the code and look for differences, then.

[I don't use gcc-2.95, yet, otherwise I'ld jump into that myself...]

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019