This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make file transfer commands work with all (native) targets.
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: tromey at redhat dot com, gdb-patches at sourceware dot org
- Date: Fri, 28 Jun 2013 22:07:58 +0300
- Subject: Re: [PATCH] Make file transfer commands work with all (native) targets.
- References: <1371835506-15691-1-git-send-email-tromey at redhat dot com> <1371835506-15691-5-git-send-email-tromey at redhat dot com> <51C880C5 dot 6050307 at redhat dot com> <87bo6rmhin dot fsf at fleche dot redhat dot com> <51CDBAF6 dot 4040209 at redhat dot com> <83txkidtap dot fsf at gnu dot org> <51CDD537 dot 3040300 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 28 Jun 2013 19:25:59 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: tromey@redhat.com, gdb-patches@sourceware.org
>
> Yeah, I admit it fits more in the general "as fewer differences
> we have between local/remote debugging, the better" theme than
> driven by a particular use case. A possible example would be something
> like gdb scripts working the same whether connected to a remote
> or local target (and unaware of whether the local target is implemented
> by local gdbserver or the native built-in target).
But putting files on a remote target puts them on the board, no?
There's no analogous place in native debugging.
> > Without a good use case, having "remote get" serve like a poor man's
> > 'cp' is confusing, IMO.
>
> Would you be OK with, or prefer, adding "target get/put/delete", leaving
> the "remote" variants in place?
I guess so, but then won't you lose backward compatibility?