X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Date:	Sun, 11 Nov 2012 20:49:13 +0200
From:	Eli Zaretskii <eliz AT gnu DOT org>
Subject:	Re: Difficulties using DJGPP 2.04 together with DOSLFN 0.41 on MSDOS 6.22
In-reply-to:	<509FE38A.9030207@gmx.de>
X-012-Sender:	halo1 AT inter DOT net DOT il
To:	Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
Cc:	djgpp AT delorie DOT com
Message-id:	<83sj8gvuty.fsf@gnu.org>
References:	<509FE38A DOT 9030207 AT gmx DOT de>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Sun, 11 Nov 2012 18:42:34 +0100
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> 
> I have tried to compile a simple "hello world" like program.  I have used MSDOS 6.22
> together with DOSLFN 0.41 (used options  ~- t+; this means that no numeric tail
> will be created).  I have used djdev204, gcc472b, bnu223b and CWSDPMI r7 without
> activated swap file.  The system has 64 MB.  The program crashes with the
> following stack trace:
> 
>    Stack Fault at eip=1902d; flags=3293
>    eax=11000000 ebx=00000000 ecx=00000000 edx=00000000 esi=4f575c3a edi=4407712f
>    ebp=415c4b52 esp=00000781 cs=e7 ds=ef es=ef fs=cf gs=0 ss=cf error=0000
> 
> 
> It makes no difference if I use gcc471b and bnu222br4.  It crashes in the same
> way.  If I try to debug the program, I get the following output:
> 
>    GNU gdb (GDB) 7.5
>    [snip]
>    Reading symbols from d:/work/a.exe...Dwarf Error: wrong version in compilation
>    unit header (is 0, should be 2, 3, or 4) [in module d:/work/a.exe]
>    (gdb) q

Does GDB say that even if you remove DOSLFN, reboot, and then try
debugging the program?  If so, I'd suspect file I/O functions that
somehow write corrupted data to the executable.

One way to dig into this would be to run objdump on the binary
compiled with DOSLFN, then on the same program compiled without
DOSLFN, and compare the results.

Once you've established that file I/O under DOSLFN is the problem, I'd
try disabling the LFN DOS calls in functions like _write and see if
that helps.  Or maybe diff the sources of v2.04 against v2.03, and see
which functions had changes in the LFN parts -- this could give you
ideas what functions could trigger a bug in DOSLFN.

Yes, it's a large job, sorry.

- Raw text -