Message-Id: <5.0.2.1.0.20010109194232.0274eec0@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 19:52:02 -0500 To: Eli Zaretskii From: "Peter J. Farley III" Subject: Re: Fw: Patch for statfs.c Cc: djgpp-workers AT delorie DOT com, Martin Str|mberg , ceo AT nbensacomputers DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20010108231043 DOT 03469460 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk At 10:03 AM 1/9/01 +0200, Eli Zaretskii wrote: >Does the version in fil316s.zip differ from what's in stock v2.03 >libc? If so, it's possible that you are right (I didn't build the >current fil316b.zip on SimTel, so I don't know for sure). Yes, but only in seemingly minor ways. Here are the two versions: N:\>dir o:\gnu\filutil3.16\djgpp\statfs.c Directory of O:\gnu\filutil3.16\djgpp STATFS C 4,707 03-29-97 11:48a statfs.c 1 file(s) 4,707 bytes 0 dir(s) 633,094,144 bytes free N:\>dir statfs.c Directory of N:\ STATFS C 4,797 08-04-99 3:58p statfs.c 1 file(s) 4,797 bytes 0 dir(s) 1,290,010,624 bytes free Here is the diff command I ised to see what was different: N:\>diff -u o:/gnu/filutil3.16/djgpp/statfs.c statfs.c>statfs97.dif And here is the result of the diff: =========statfs97.dif================ --- o:/gnu/filutil3.16/djgpp/statfs.c Sat Mar 29 11:48:10 1997 +++ statfs.c Wed Aug 4 15:58:24 1999 @@ -1,14 +1,16 @@ +/* Copyright (C) 1999 DJ Delorie, see COPYING.DJ for details */ +/* Copyright (C) 1998 DJ Delorie, see COPYING.DJ for details */ /* Copyright (C) 1997 DJ Delorie, see COPYING.DJ for details */ /* Copyright (C) 1995 DJ Delorie, see COPYING.DJ for details */ +#include +#include #include #include -#include +#include #include -#include #include #include #include -#include #include int @@ -19,10 +21,11 @@ int cdrom_calls_used = 0; int blocks = 0; - /* Get the drive number */ - if (path[0] && path[1] == ':') - drive_number = (path[0] & 0x1f) - 1; - else + /* Get the drive number, including the case of magic + names like /dev/c/foo. */ + _put_path(path); + drive_number = (_farpeekb(_dos_ds, __tb) & 0x1f) - 1; + if (_farpeekb(_dos_ds, __tb + 1) != ':' || drive_number == -1) { regs.h.ah = 0x19; __dpmi_int(0x21, ®s); =========statfs97.dif================ >In any case, I think we need to understand the cause for the >discrepancy, because it might provide us with the solution to the >problem of slightly incorrect size. > >> Can objdump be used to extract just one function's code from an >> executable? > >What do you mean by that? Do you want to see the disassembly of a >single function? Yes. >> If we could extract just the statfs function, we could >> diff the output of objdump of the statfs code from the distributed >> binary and the current libc version of statfs to see how they are >> different. > >That won't be easy, I'm afraid: differences in compiler and Binutils >versions and switches can produce changes on the assembly level that >completely obscure the real code differences. Oh well, it was just an idea. >It is much easier to try several avaiable versions of statfs, since >the number of these versions is small (like 3 or something). Agreed, that seems to be the only way. The problem is, I can't get any of the versions I've tried so far to give the results that df from fil316b.zip gives. I will try building fil316s.zip with the stock v2.03 libc.a and see what results I get from that. It's the only one I haven't tried yet. --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)