This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] File-I/O, target access to host file system via gdb remote protocol enhancement


On Wed, Nov 13, 2002 at 10:09:42AM -0500, Daniel Jacobowitz wrote:
> On Wed, Nov 13, 2002 at 03:51:54PM +0100, Corinna Vinschen wrote:
> > 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?

No, it isn't.  I tried to find a well defined behaviour.  The target
shouldn't be forced to know much about it's host.  Quote from my proposal:

  Memory transfer:

    Structured data which is transferred using a memory read or write
    packet as e.g. a struct stat is expected to be in a protocol specific
    format with all numerical multibyte datatypes being big endian.
    [...]

> > 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?

Yes, probably you're right.  But actually, gdb could fake everything. 
That's not barred by the protocol.  So, in theory, we could write a gdb
for a host which itself has no file system, faking a file system to its
remote target.  Ok, that's academically, but I like the idea :-)

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]