From: "Alexei K." <kzua AT kzua DOT udm DOT ru>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: SIGILL 386 (illegal opcode)
Date: Thu, 1 May 2003 14:29:32 +0500
Organization: Communication Company MARK-ITT
Lines: 82
Message-ID: <b8qpgj$2tb4$1@hq.mark-itt.ru>
References: <b8oqgi$1s2b$1 AT hq DOT mark-itt DOT ru> <3eb08a5a$0$79355$cc7c7865 AT news DOT luth DOT se>
NNTP-Posting-Host: d2-215.net.mark-itt.net
Mime-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 8bit
X-Trace: hq.mark-itt.ru 1051781459 95588 217.14.194.215 (1 May 2003 09:30:59 GMT)
X-Complaints-To: abuse AT mark-itt DOT ru
NNTP-Posting-Date: Thu, 1 May 2003 09:30:59 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Martin Str|mberg" <ams AT speedy DOT ludd DOT luth DOT se> сообщил/сообщила в новостях следующее:
news:3eb08a5a$0$79355$cc7c7865 AT news DOT luth DOT se...
> If you get SIGILL we want more information. Like what program and
> source? Command line? Result?

My project works fine with 386 CPU, if it compiles by DJGPP gpp 2.952.
I have just recompiled my project by DJGPP gpp 3.2.2
(with -m386 option enabled) and program has failed only on 386 PC.
I deeply use STL. Was libstdxx.a library compiled for 386 CPU?
How can I rebuild libstdxx.a?
My problem seems to be similar to which I have found in
comp.os.msdos.djgpp archive on www.google.com.

-------------------------------------------

Letter #1:
Rob Kramer (robk AT cyberway DOT com DOT sg)
Subj: GCC 2.95 global string crashes on 386..
For some reason using a global STL 'string' crashes my program if run on a
386 machine. Take the following testcase:
-----------
#include <iostream>
#include <string>

string foo = "bar";

void main()
{
  cout << "test: " << foo << endl;
}
-----------

Compiled with 'gpp -o test.exe test.cc'  (gcc 2.95, bnu 291), this crashes:

Letter #2:
Rob Kramer (robk AT cyberway DOT com DOT sg)
Re: GCC 2.95 global string crashes on 386..
I've disassembled the executable, and it seems the compiler issues a locked
'xaddl' instruction. I couldn't find opcode 'c1' in my 386 reference manual,
so this may be a 486++ instruction?   (I can't find anything but Intel's 386
manual online, sigh)

    2052: f0 0f c1 02     lock xaddl %eax,(%edx)

> Confirmed with DJGPP ports of egcs-1.1.2 and gcc-2.95.1 (I don't more
> gcc-2.95 installed, but that doesn't matter). 2 possible cures:
>  - currently use option '-march=i386' on 386, it should help

I tried that already, to no avail.. Tried again, and the compiler outputs the
same 'xaddl' at a slighty different location (other parts of the code are
different)

>  - in future: I must rebuild gcc-2.95.1 for target i386-pc-msdosdjgpp

Hmm. How come that in thousands of lines of code, the compiler only fails in
a global string definition..

Letter #3:
Horst Kraemer (horst DOT kraemer AT snafu DOT de)
> I've disassembled the executable, and it seems the compiler issues a locked
> 'xaddl' instruction. I couldn't find opcode 'c1' in my 386 reference manual,
> so this may be a 486++ instruction?

Yes.  The XADD instruction was introduced with 486 and produces
nonsense or a crash on a 386- system, of course,

> (I can't find anything but Intel's 386
> manual online, sigh)
>
>     2052: f0 0f c1 02     lock xaddl %eax,(%edx)

The effect is that (edx) will contain the sum of (edx) and eax, just
as for a normal add, but eax will not retain its old value but it gets
the old value of (edx).

-------------------------------------------

I have not found the solution of the problem shown above.
So, What is the solution?

Alexei K.