Mail Archives: djgpp/2012/03/13/23:00:09
On Tuesday, March 13, 2012 6:36:06 PM UTC-7, Claude Freeman wrote:
> Hello!
>
> 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.
>
> here is the output of all I can give you thus far.
>
> My SET environment...
>
>
> TMP=C:\WINDOWS\TEMP
> TEMP=C:\WINDOWS\TEMP
> PROMPT=$p$g
> winbootdir=C:\WINDOWS
> COMSPEC=C:\WINDOWS\COMMAND.COM
> SOUND=C:\PROGRA~1\CREATIVE\CTSND
> MIDI=SYNTH:1 MAP:E
> windir=C:\WINDOWS
> BLASTER=A220 I5 D1 H1 P330 T6
> PATH=C:\DJGPP\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND
> DJGPP=c:\djgpp\djgpp.env
> CMDLINE=gcc foo.c -v
>
> The nasty crash dialog I get (there's no dump, for some unknown reason)
>
> When compiling the program with -v , I'll get some output but it's only declaring flags and whatnot:
>
> C:\REMOOD>gcc foo.c -v
> Using built-in specs.
> COLLECT_GCC=c:/djgpp/bin/gcc.exe
> COLLECT_LTO_WRAPPER=c:/djgpp/bin/../libexec/gcc/djgpp/4.62/lto-wrapper.exe
> Target: djgpp
> Configured with: /v203/gcc-4.62/configure djgpp --prefix=/dev/env/DJDIR --disable-nls --disable-werror --enable-languages=c,c++,fortran,objc,obj-c++,ada -enable-libquadmath-support
> Thread model: single
> gcc version 4.6.2 (GCC)
> COLLECT_GCC_OPTIONS='-v' '-mtune=pentium' '-march=pentium'
> c:/djgpp/bin/../libexec/gcc/djgpp/4.62/cc1.exe -quiet -v -iprefix c:/djgpp/bin/../lib/gcc/djgpp/4.62/ -remap foo.c -quiet -dumpbase foo.c -mtune=pentium -march=pentium -auxbase foo -version -o c:/djgpp/tmp/ccDUEyWn.s
> Exiting due to signal SIGILL
> Invalid Opcode at eip=007bbdc8
> eax=006153eb ebx=00ba4738 ecx=00ba4740 edx=00615779 esi=00ba4740 edi=00aa4774
> ebp=00ba474c esp=00ba4734 program=C:\DJGPP\LIBEXEC\GCC\DJGPP\4.62\CC1.EXE
> cs: sel=00ff base=8310e000 limit=00baffff
> ds: sel=0107 base=8310e000 limit=00baffff
> es: sel=0107 base=8310e000 limit=00baffff
> fs: sel=00df base=00013350 limit=0000ffff
> gs: sel=0117 base=00000000 limit=0010ffff
> ss: sel=0107 base=8310e000 limit=00baffff
> App stack: [00ba4774..00aa4774] Exceptn stack: [00aa417c..00aa223c]
>
> Call frame traceback EIPs:
> 0x007bbdc8
> 0x007a5295
> 0x0079bb17
>
>
> go32's output:
>
>
> go32/v2 version 2.0 built Dec 24 2001 21:25:02
> Usage: go32 coff-image [args]
> Rename this to go32.exe only if you need a go32 that can run v2 binaries as
> well as v1 binaries (old makefiles). Put ahead of the old go32 in your PATH
> but do not delete your old go32 - leave it in the PATH after this one.
> Set GO32_V2_DEBUG=y in the environment to get verbose output.
>
> DPMI memory available: 25832 Kb
> DPMI swap space available: 6232 Kb
>
> My CONFIG.SYS (only loads my CD-ROM):
>
>
> REM device=\bpcdrom\bpcddrv.sys /d:bpcddrv$
> DEVICEHIGH=C:\WINDOWS\COMMAND\DRVSPACE.SYS /MOVE
>
> My AUTOEXEC.BAT:
>
> SET SOUND=C:\PROGRA~1\CREATIVE\CTSND
> SET MIDI=SYNTH:1 MAP:E
> SET BLASTER=A220 I5 D1 H1 P330 T6
>
>
> If it helps further, here is what running GDB on CC1.EXE gets:
>
> GNU gdb (GDB) 7.4
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i586-pc-msdosdjgpp --target=djgpp".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from C:\DJGPP\LIBEXEC\GCC\DJGPP\4.62\CC1.EXE...(no debugging sym
> bols found)...done.
> (gdb) run
> Starting program: C:\DJGPP\LIBEXEC\GCC\DJGPP\4.62\CC1.EXE
>
> Program received signal SIGILL, Illegal instruction.
> 0x007bbdc8 in ?? ()
> (gdb) bt
> #0 0x007bbdc8 in ?? ()
> #1 0x007a5295 in ?? ()
> #2 0x0079bb17 in ?? ()
> #3 0x00001c36 in ?? ()
>
>
>
> I've hit a brick wall here. Everything else in the DJGPP distro seems to act sane, for the most part. too bad the most important part is refusing to work.
>
> Any ideas? I've done done CPU checks and memtests, everything checks out OK.
I know I am not the person who could do anything about it, but I am sure they will ask: what's the source code for foo.c? can you narrow it down to a very small reproducible test case?
those are the kinds of things they usually ask for. also, for a compiler bug, they will usually want the .ii file when you do a
gcc -v -save-temps foo.c
especially if it's a gcc bug and not just a djgpp bug.
- Raw text -