Re: RFC: File transfer commands

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> Two years ago, I worked on a GDB port to SymbianOS.  The SymbianOS
> target was interesting in a couple of ways that required changes to
> GDB.  One was the target shared library list, which is included in
> GDB 6.7.  Another was the need to specify a running process to attach
> to over a remote connection, which I'll be posting about in a few days
> or a week.  And a third way was the need for file transfer commands.

That's interesting, as remote file transfer is on my current to-do
list ;-)   I'd like to remove the requirement to have exact copies
of target shared libraries available on the host system when doing
remote debugging via gdbserver; this is an annoyingly frequent cause
of user complaints ...   To fix this, I'm thinking of extending the
shared library layer to directly access the shared library files
available on the target instead of searching for copies on the host.
This would use some sort of file access via the remote protocol.

> Here is the documentation I've written for it.  There are three new
> CLI commands (remote put, remote get, remote delete); three new MI
> commands (-target-file-put, -target-file-get, -target-file-delete);
> and five new remote protocol packets (vFile:open, vFile:close,
> vFile:pread, vFile:pwrite, vFile:unlink).  I'm not committed to any
> of the command names or packets; alternatives welcome.
> 
> Should GDB have this feature?  Are these the right commands for it?

Hmm, I'd have chosen to use a new target object (TARGET_OBJECT_FILE)
and corresponding qXfer packet; the "annex" would obviously be the
remote file name.

However, that would not support unlink, and it would cause the 
target to re-open the file for each access.  That wouldn't matter
for my intended use scenario, not sure if it would in yours ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com