Mail Archives: djgpp-workers/2001/05/20/10:53:58
Hello.
I think I've found the solution to the problem. You can probably skip to
the end, just after the mem /c output, if you're not interested in the
middle part of the analysis.
Eli Zaretskii wrote:
>
> On Mon, 14 May 2001, Richard Dawe wrote:
> > The program encountered an unspecified exception.
> >
> > Fault location: 018F:10B8
> >
> > Interrupts in service: None
>
> 10B8h looks like the entry point to DJGPP programs, or somewhere very
> close to that. And 018Fh looks like a selector Windows allocates for
> a program nested maybe 2-3 levels deep. ``Unspecified exception''
> puzzles me: seems like Windows cannot keep track of what exception it
> got?
>
> You can see if 10B8h is the entry point for the program you are
> running at the moment of crash like this:
>
> objdump -f PROG.exe
>
> If it doesn't print 0x10b8 as the starting point, please tell what
> value exactly it does print.
NB: this crash is caused by running Fileutils configure script with
-nostdinc and -nostdlib parameters with parameters to point at CVS headers
& libraries.
I had not noticed before that the title bar is set to "go32-v2" at the
time of the crash. So I built debug and non-debug versions from the DJGPP
2.03 sources from dj{dev,lsr,tzs}203.zip with gcc 2.95.3, binutils 2.10.
Here's what objdump says about each of them:
bash-2.04$ for i in /djgpp/bin/go32-v2.exe*; do objdump -f $i; done
/djgpp/bin/go32-v2.exe: file format coff-go32-exe
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x000010b0
/djgpp/bin/go32-v2.exe.debug: file format coff-go32
architecture: i386, flags 0x00000136:
EXEC_P, HAS_LINENO, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x000010b0
/djgpp/bin/go32-v2.exe.orig: file format coff-go32-exe
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x000010a8
go32-v2.exe.orig is the stock go32-v32 from djdev203.zip. As you can see
the original crash occurred 0x10 bytes after the start address.
OK, this is strange. A debug build of go32-v2 does not cause a crash. A
normal build of go32-v2 does crash. It crashes at 0x10b8 still! What would
be different between a normal & debug build of go32-v2?
Normal go32-v2 built from DJGPP CVS also has a start address of 0x10b0 and
also crashes.
I wonder if anyone else can duplicate this problem. Here is my script for
configuring against CVS:
#! /bin/sh -x
CVSDIR=c:/develop/djgpp
export CONFIG_SITE=djgpp/config.site
aclocal -I m4
autoheader
automake --gnits --include-deps Makefile
automake --gnits --include-deps m4/Makefile
autoconf
#CFLAGS="-g -O2 -I$CVSDIR/include" \
# LDFLAGS="-g -O2 -L$CVSDIR/lib" \
# ./configure --disable-nls
# LIBS=$CVSDIR/lib/libc.a \
# go32-v2 crashes when I try this!
#CC=echo \
CFLAGS="-v -g -O2 -nostdinc -I$CVSDIR/include" \
LDFLAGS="-v -g -O2 -nostdlib -L$CVSDIR/lib" \
LIBS=-lc \
./configure --disable-nls
[ To configure against CVS sources I actually use: ]
[ ]
[ CFLAGS="-g -O2 -I$CVSDIR/include" \
]
[ LDFLAGS="-g -O2 -L$CVSDIR/lib" \
]
[ ./configure --disable-nls ]
> Perhaps looking at crt0.S at the appropriate offset could give a clue
> about the nature of the problem.
> You can see what code is at the offending address like this:
>
> gdb PROG.exe
> (gdb) disassemble 0x10b8
Unfortunately this does not work for me for me on the non-debug versions
with gdb 4.18 - I get the error:
No function contains specified address.
On the debug version I get the following dump:
Dump of assembler code for function start:
0x10b0 <start>: push %ds
0x10b1 <start+1>: pop %es
0x10b2 <start+2>: testb $0x1,0x16aa5
0x10b9 <start+9>: jne 0x10e0 <start+48>
0x10bb <start+11>: mov $0x10b0,%eax
0x10c0 <start+16>: cmp $0x1000,%eax
0x10c5 <start+21>: jl 0x10e0 <start+48>
0x10c7 <start+23>: mov $0x507,%ax
so it crashes right at the start of the code in crt0.S. 'objdump -d' gives
similar disassembly for the versions I've built with gcc 2.95.3, i.e.
0x10b8 is between:
0x10b2 <start+2>: testb $0x1,0x16aa5
0x10b9 <start+9>: jne 0x10e0 <start+48>
but the stock 2.03 go32-v2 has this:
000010a8 <.text>:
10a8: 1e push %ds
10a9: 07 pop %es
10aa: f6 05 25 5a 01 00 01 testb $0x1,0x15a25
10b1: 75 25 jne 0x10d8
10b3: b8 a8 10 00 00 mov $0x10a8,%eax
10b8: 3d 00 10 00 00 cmp $0x1000,%eax
10bd: 7c 19 jl 0x10d8
10bf: 66 b8 07 05 mov $0x507,%ax
10c3: 64 8b 35 18 00 00 00 mov %fs:0x18,%esi
10ca: 31 db xor %ebx,%ebx
10cc: b9 01 00 00 00 mov $0x1,%ecx
10d1: ba 76 14 01 00 mov $0x11476,%edx
This seems to eliminate testb as causing the exception.
> Anyway, this does look like depletion of some resources, but I'm
> unsure which resources. Charles, any ideas?
>
> One possible problem could be DOS memory. What does "mem /c" print in
> that DOS box?
Modules using memory below 1 MB:
Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
MSDOS 29,248 (29K) 29,248 (29K) 0 (0K)
HIMEM 1,168 (1K) 1,168 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
SETVER 832 (1K) 832 (1K) 0 (0K)
DISPLAY 8,304 (8K) 8,304 (8K) 0 (0K)
OAK_CD 20,384 (20K) 20,384 (20K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
IFSHLP 2,864 (3K) 2,864 (3K) 0 (0K)
WIN 3,904 (4K) 3,904 (4K) 0 (0K)
vmm32 16,496 (16K) 16,496 (16K) 0 (0K)
SBEINIT 4,480 (4K) 4,480 (4K) 0 (0K)
KEYB 6,944 (7K) 6,944 (7K) 0 (0K)
DOSKEY 4,688 (5K) 4,688 (5K) 0 (0K)
BASH 18,064 (18K) 18,064 (18K) 0 (0K)
Free 529,872 (517K) 529,872 (517K) 0 (0K)
Memory Summary:
Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 125,488 529,872
Upper 0 0 0
Reserved 0 0 0
Extended (XMS) 67,043,328 ? 132,636,672
---------------- ----------- ----------- -----------
Total memory 67,698,688 ? 133,166,544
Total under 1 MB 655,360 125,488 529,872
Largest executable program size 529,856 (517K)
Largest free upper memory block 0 (0K)
MS-DOS is resident in the high memory area.
My machine has 128MB. I have a DOS CD driver loaded (OAK_CD) and some
Sound Blaster software. I'm running Win98 SE with some updates applied via
Windows Update.
The actual problem
==================
It turns out that gcc is not generating a valid program - unsurprising
since I was using the -nostdlib flag. Here is the extract from configure
that tests that the C compiler works:
---Start configure extract---
cat > conftest.$ac_ext << EOF
#line 987 "configure"
#include "confdefs.h"
main(){return(0);}
EOF
if { (eval echo configure:992: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }
&& test -s conftest${ac_exeext}; then
ac_cv_prog_cc_works=yes
# If we can't run a trivial program, we are probably using a cross
compiler.
if (./conftest; exit) 2>/dev/null; then
ac_cv_prog_cc_cross=no
else
ac_cv_prog_cc_cross=yes
fi
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
ac_cv_prog_cc_works=no
fi
rm -fr conftest*
---End configure extract---
Here's the section in config.log:
---Start config.log extract---
configure:992: gcc -o conftest -v -g -O2 -nostdinc
-Ic:/develop/djgpp/include -v -g -O2 -nostdlib -Lc:/develop/djgpp/lib
conftest.c -lc 1>&5
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs
gcc version 2.95.3 20010315/djgpp (release)
c:/djgpp/lib/gcc-lib/djgpp/2.953/cpp0.exe -lang-c -nostdinc -v
-Ic:/develop/djgpp/include -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dunix -Di386
-DGO32 -DDJGPP=2 -DMSDOS -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2
-D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS
-Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__
-g -g -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__
-D__tune_pentium__ -imacros c:/djgpp/lib/djgpp.ver -remap conftest.c
c:\temp\cc9w9IaI.i
GNU CPP version 2.95.3 20010315/djgpp (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
c:/develop/djgpp/include
End of search list.
The following default directories have been omitted from the search path:
$DJDIR/lang/cxx
$DJDIR/lib/gcc-lib/djgpp/2.953/../../../../djgpp/include
$DJDIR/lib/gcc-lib/djgpp/2.953/include
$DJDIR/include
End of omitted list.
c:/djgpp/lib/gcc-lib/djgpp/2.953/cc1.exe c:\temp\cc9w9IaI.i -quiet
-dumpbase conftest.c -g -g -O2 -O2 -version -o c:\temp\ccyj3jNj.s
GNU C version 2.95.3 20010315/djgpp (release) (djgpp) compiled by GNU C
version 2.95.3 20010315/djgpp (release).
c:/djgpp/bin/as.exe -o c:\temp\cczt5zN3.o c:\temp\ccyj3jNj.s
c:/djgpp/lib/gcc-lib/djgpp/2.953/collect2.exe -o conftest
-Lc:/develop/djgpp/lib -Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/2.953
-Lc:/djgpp/bin -Lc:/djgpp/lib c:\temp\cczt5zN3.o -lc -Tdjgpp.djl
c:/djgpp/bin/ld.exe: warning: cannot find entry symbol start; defaulting
to 000010a8
c:/djgpp/bin/stubify.exe -v conftest
stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie
stubify: conftest -> conftest.exe
---End config.log extract---
"c:/djgpp/bin/ld.exe: warning: cannot find entry symbol start; defaulting
to 000010a8" is the key, I think. Since ld has not generated a valid
executable, it is hardly surprising that the program causes an exception
when run by the configure script.
So this is user error. Pardon me for any confusion caused.
Thanks, bye, Rich =]
--
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/
- Raw text -