This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] File-I/O, target access to host file system via gdb remote protocol enhancement
On Wed, Nov 13, 2002 at 03:51:54PM +0100, Corinna Vinschen wrote:
> On Wed, Nov 13, 2002 at 09:31:40AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Nov 13, 2002 at 02:35:22PM +0100, Corinna Vinschen wrote:
> > > On Tue, Nov 12, 2002 at 04:25:26PM -0500, Daniel Jacobowitz wrote:
> > > > Ick, 32-bit st_ino... why bother to transfer it if you say "no meaning
> > > > for the target"?
> > >
> > > The point is mainly to have all fields available which a POSIX compliant
> > > application may expect.
> >
> > Right; but you require that the stub convert to host format anyway, so
>
> In case of the stat structure it's always gdb which creates/sends the
> structure. The struct is filled by gdb on behalf of the target OS.
> I'm not aware of a system call which takes a stat struct as input parameter.
Right. Sorry, I meant "you require the stub to convert _from_ host
format" - isn't that correct? So if you are explicitly defining the
st_ino field to have a useless value, I don't see why you're sending it
over the wire. This is a nit; it's not important.
> > it seems odd to send the unused members over the wire. I guess they
> > might be used someday.
>
> So you'd change st_ino to 64 bit?
It offends my sense of elegance but I don't see a reason to bother -
not when you've already got a stub using this. Any application that
relies on a property of st_ino probably wants to have a real filesystem
anyway, right?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer