delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/01/08/23:20:06

Message-Id: <5.0.2.1.0.20010108231043.03469460@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 08 Jan 2001 23:21:43 -0500
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: "Peter J. Farley III" <pjfarley AT banet DOT net>
Subject: Re: Fw: Patch for statfs.c
Cc: djgpp-workers AT delorie DOT com, Martin Str|mberg <ams AT ludd DOT luth DOT se>,
ceo AT nbensacomputers DOT com
In-Reply-To: <Pine.SUN.3.91.1010108085114.4690F-100000@is>
References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20010107121357 DOT 00aa6580 AT pop5 DOT banet DOT net>
Mime-Version: 1.0
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

At 09:00 AM 1/8/01 +0200, Eli Zaretskii wrote:
 >
 >On Sun, 7 Jan 2001, Peter J. Farley III wrote:
 >
 >> Note that the rebuilt df reports too many 1024 blocks, 326552*1024 
=
 >> 334389248 while 325888*1024 = 333709312.  The difference is 664
 >blocks,
 >> which I cannot explain easily.
 >
 >Since two versions of statfs which are supposed to be identical 
return
 >different values, I think the only way to find out why is to step 
inside
 >
 >both versions with a debugger and see where does the difference come
 >from.  Perhaps there's some bug in how the transfer buffer is layed 
out
 >when passing requests to the CDROM driver vie Int 2Fh.

Could it be that fil316b.zip was built with the older version of statfs 
that is packaged in the fil316s.zip archive (which might explain the 
difference)?

Can objdump be used to extract just one function's code from an 
executable?  If so, what are the switches to use?  I've reviewed the 
objdump info and there doesn't seem to be a way to specify the 
*function* name to be extracted (unless I'm blanking out and not seeing 
it), just the "section", which apparently means things like ".text", 
".bss", etc.  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.

I can and will also test that old version of statfs from fil316s.zip by 
itself, to see if it returns the values I see from the distributed 
df.exe.

 >> Filesystem         1024-blocks  Used Available Capacity Mounted on
 >> EXCALIBUR_16X9_FF_NA 6729942 6729942        0    100%   y:/
 >[snip]
 >>           0 file(s)              0 bytes
 >>           1 dir(s)            0.00 MB free
 >>                           6,572.21 MB total disk space, 100% in use
 >
 >Please make a point of showing the numbers in the same units.  It is
 >very
 >annoying to grab a calculator or invoke Calc each time to compare the 

 >reported sizes.
 >
 >According to my calculations, 6,572.21 MB is exactly 6729943 bytes, 
so
 >these two numbers are consistent.  Is that what you wanted to say?

Yes, that is what I wanted to say.  I will recalculate the numbers as 
you request in future posts.

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019