Mail Archives: djgpp/2005/07/18/20:31:52
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)
|
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
- Raw text -