Mail Archives: djgpp/2012/03/14/23:15:15
Hi,
On Mar 14, 1:16 pm, Andris Pavenis <andris DOT pave DOT DOT DOT AT iki DOT fi> wrote:
> On 14.3.2012 2:36, Claude Freeman wrote:
>
> > I have a Pentium MMX CPU with around 48 MB RAM. I run Win95c, It's mostly for simple programming practice. I'm trying to use DJGPP to compile a simple hello world program in C, yet instead of a pretty program I get crash dump on my face.
>
> I only verified build on Core2 where I built
> (I do not have anything older).
I can't test my older hardware (easily), so I was stuck to DOSBox,
which also behaves similarly.
> Exiting due to signal SIGILL
> Invalid Opcode at eip=007bbdc8
>
> Call frame traceback EIPs:
> 0x007bbdc8 init_vectorized_lexer+141, file insn-recog.c
>
> From GDB one gets:
>
> (gdb) disass init_vectorized_lexer
> Dump of assembler code for function init_vectorized_lexer:
> 0x007bbdc8 <+141>: cmove %eax,%edx
> End of assembler dump.
> (gdb)
Yeah, GCC is notorious for (over)using CMOVxx when targeting i686.
BTW, this part is apparently part of /libcpp/lex.c , if that helps
any. I have no idea why GCC would have this bug, esp. since they make
great pains to utilize CPUID.
http://www.delorie.com/djgpp/dl/ofc/current/v2gnu/gcc462s.zip/gnu/gcc-4.62/libcpp/lex.c
> According tohttp://en.wikipedia.org/wiki/X86_instruction_listings
> instruction CMOVE is added in Pentium Pro, so Pentium MMX
> does not have it
Not sure even all PPros had it, nor other weirdos (VIA C3?). But yeah,
apparently these days it's hard for such bugs not to hide. :-(
> So it seems that specifying host machine does not seem to be sufficient
> any more (even it shoud be sufficient). I had:
>
> build=i586-pc-msdosdjgpp
> host=i586-pc-msdosdjgpp
> target=i586-pc-msdosdjgpp
>
> in generated Makefile in directory gcc for stage 3.
What version of GCC was used to build this one (initially? finally?)?
I assume you (typically) bootstrapped with itself.
> It seems that all 4.6.X versions have the same problem (I checked
> disassembler output for 4.6.0).
I did a quick search, but it seemed like they (mistakenly thought
they) fixed it already. Ugh.
It has to be some simple configuration error somewhere. Perhaps it's
something dumb like the GCC frontend driver not compiling /
accepting .S files (via BinUtils) with 686 instructions without "-
march=i686" or higher (as there was such a weird change a while back,
IIRC).
BTW, if GCC wasn't such a ***pain*** to rebuild (which I'm constantly
failing at doing), I'd try for you here. But every time I try, it's
always something that fails horribly. So I never even bothered
downloading 60+ MB of sources for 4.6.2. (Even the 4.x ones I do have
never rebuilt properly. It's really a mess, sorry, I just hate the
messy organization of it, the whole build process is annoying.)
> Currently I can only suggest to
> try older version (for example some 4.5.X,
> 4.4.X, etc). It would be nice to get
> feedback about results.
In fairness, that Win95 machine is much too underpowered for such a
huge pig as "latest" GCC. (Did Win95 ever do demand paging? I assume
not. In other words, I'd be surprised if the latest 10 MB CC1.EXE
wouldn't waste tons of your RAM, and certainly you don't "seem" to be
booting raw MS-DOS 7 here, not that it would help much.)
I would strongly suggest something like GCC 3.4.4 or similar (or even
my slimmed one-floppy 2.95.3 C-only version). Though I doubt the OP
really wants those.
- Raw text -