This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Fix compilation failure of remote-fileio.c
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Eli Zaretskii <eliz at elta dot co dot il>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 28 Dec 2003 18:38:00 -0500
- Subject: Re: [RFC] Fix compilation failure of remote-fileio.c
- References: <ubrpt6odu.fsf@elta.co.il>
On Sun, Dec 28, 2003 at 03:52:13PM +0200, Eli Zaretskii wrote:
> remote-fileio.c won't compile if `struct stat' doesn't have the
> `st_blocks' member. The patch below fixes that, but I'm not sure it
> (and the associated patch to gdb/configure.in, which is not shown
> below) is the right fix. Is it perhaps better not to use st_blocks at
> all, and instead compute the number of blocks as shown by the patch,
> for all platforms?
Probably not. If it's correct for DJGPP then it's a bit of an
accident.
The reason it isn't correct in general:
blksize_t st_blksize; /* blocksize for filesystem I/O */
blkcnt_t st_blocks; /* number of blocks allocated */
It's not clear from those comments, but st_blksize is the "optimal IO
size":
The value st_blocks gives the size of the file in 512-byte
blocks. (This may be smaller than st_size/512 e.g. when the
file has holes.) The value st_blksize gives the "preferred"
blocksize for efficient file system I/O. (Writing to a file in
smaller chunks may cause an inefficient read-modify-rewrite.)
So you probably want st->st_size / 512 instead.
> +#else
> + remote_fileio_to_fio_ulong ((LONGEST) st->st_size / (LONGEST) st->st_blksize
> + + ((LONGEST) st->st_size % (LONGEST) st->st_blksize) != 0,
> + fst->fst_blocks);
> +#endif
A marginally more efficient way to write this is:
((LONGEST) st->st_size + st->st_blksize - 1) / st->st_blksize
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer