Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3B07CA85.7DDE69D5@phekda.freeserve.co.uk> Date: Sun, 20 May 2001 14:45:41 +0100 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com CC: Charles Sandmann Subject: Re: Fileutils 4.0 and symlinks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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 : push %ds 0x10b1 : pop %es 0x10b2 : testb $0x1,0x16aa5 0x10b9 : jne 0x10e0 0x10bb : mov $0x10b0,%eax 0x10c0 : cmp $0x1000,%eax 0x10c5 : jl 0x10e0 0x10c7 : 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 : testb $0x1,0x16aa5 0x10b9 : jne 0x10e0 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/