X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <42DC0DC7.7080200@vtc.edu>
Date: Mon, 18 Jul 2005 20:15:03 +0000
From: Sam Colwell <scolwell AT vtc DOT edu>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: GPP programs don't run on a 386SX (SIGILL)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jul 2005 00:18:42.0654 (UTC) FILETIME=[6B7E27E0:01C58BF7]
Reply-To: djgpp AT delorie DOT com

I'm having a problem that looks like it used to have a solution, but 
enough has changed that I'm having trouble applying the old solution 
that I found in the mail archives.

THE BACKGROUND:
I have an embedded 386SX 25MHz board that runs FreeDOS (Beta 9) in 32MB 
RAM.  I've loaded DJGPP (djdev203, bnu216b, gcc400b, gdb611b, gpp400b, 
mak3791b, csdpmi5b) onto the machine.

I type in the following program (pardon any typos here, if there are 
any; the real source is correct):
mytest.cpp
----------------------------
#include <iostream>
int main()
{
  std::cout << "Hello World";
  return 0;
}
-----------------------------

To compile, I type:
gpp -o mytest.exe mytest.cpp

The code compiles and links fine into mytest.exe

THE PROBLEM:
When I run this program, I get a SIGILL invalid instruction error.  It 
is not easy for me to paste the error into this email (sorry).

Using objdump and the value in EIP when it crashed, I have located the 
offending instruction as:
  lock xadd %eax, 0x_some_hex_number_was_here

Looking through the archives, it appears that "lock" is a 486 
instruction, which would be why my 386 can't run it.  The offending 
instruction appears to be compiled into libstdcxx.a, which would explain 
why all of my C program work fine and all of my C++ programs have this 
error.

MY FAILED SOLUTION:
There was mention in the archives 
(http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2003/05/14/10:30:19) 
about replacing an atomicity.h file in a bits directory with a generic 
one from the source zip and rebuilding libstdcxx.a, but it looks like 
the directory structure has changed, and I can't figure out what file to 
copy where anymore.  I suppose I could have done a more thorough search 
with grep, but I figured I would ask here in case anyone knew of an 
easier solution.  It was mentioned in a post that this issue was "fixed" 
in the new releases, although this appears not to be the case.

I tried twice to recompile libstdcxx.a (and/or the entire compiler) from 
source.  I tried with gcc366s.zip because I've used that version before, 
and I could find the referenced files in the referenced directories from 
the earlier solution (compiling it with that same version (3.66) 
binary).   I also tried gcc400s.zip (again, compiling it with the same 
version (4.00) binary).  The instructions are a bit out of date as I 
couldn't find the scripts to make the makefiles where the docs said they 
might be (either that, or I am blind - I've been working on this so long 
today, that could easily be the case), but the ./configure&&make dance 
appeared to work, except that it failed with an out of memory error when 
linking.  go32-v2 reports 274M available and 0K swap (which I see is 
normal on XP Pro from reading the list archives).

WHAT I WANT:
I would like to be able to compile C++ programs and have them run on my 
386SX.
It appears I would be all set if I had a copy of libstdcxx.a without the 
lock instruction in it.  I have failed building it myself, but I would 
appreciate either someone to build a copy for me, or good directions 
(specifying exactly what zips to download and exactly what to type).  
Because this will be used in an educational setting (the embedded 386 is 
part of a trainer for a Microprocessor Techniques course at Vermont 
Technical College), I think I would like to go with the most recent 
non-brand-new version of DJGPP/gcc, which would be 3.44 (looking at the 
directory listing of all the zip files).  I tend to shy away from things 
that have versions ending in 00.

Thank for reading my rather long-winded plea for help, but hopefully I 
won't be accused of not providing enough information.

--Sam Colwell