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: Tom Tromey <tromey at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 01 Jul 2013 08:28:24 -0600
- 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> <83mwqadpf5 dot fsf at gnu dot 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).
Eli> But putting files on a remote target puts them on the board, no?
Eli> There's no analogous place in native debugging.
There's the local filesystem.
You can run gdbserver locally and still use these commands.
>> > 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?
Eli> I guess so, but then won't you lose backward compatibility?
He means to leave the "remote" variants in place.
Tom