Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH] Make file transfer commands work with all (native) targets.
Date: Fri, 28 Jun 2013 19:05:00 -0000	[thread overview]
Message-ID: <51CDD537.3040300@redhat.com> (raw)
In-Reply-To: <83txkidtap.fsf@gnu.org>

On 06/28/2013 06:44 PM, Eli Zaretskii wrote:
>> Date: Fri, 28 Jun 2013 17:33:58 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: gdb-patches@sourceware.org
>>
>>> Pedro> remote_file_get could nowadays be using the target_fileio_XXX methods
>>> Pedro> instead of remote_hostio_XXX, and therefore the command could be
>>> Pedro> generalized to work with all targets.
>>
>> Actually, doing this is quite easy, so I went ahead, in the name
>> of local/remote feature parity.  We can connect to a local gdbserver
>> and do file transfer in the local system; there seems to be no
>> reason we can't do it with native debugging too.
>>
>> WDYT?
> 
> What is the use case?

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).

> 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?  The difference between the "target" and
"remote" variants would be that the former would work with any target,
while the later would still only work with the remote target.

-- 
Pedro Alves


  reply	other threads:[~2013-06-28 18:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 17:25 [PATCH 00/16] clean up remote.c state Tom Tromey
2013-06-21 17:25 ` [PATCH 08/16] push last_program_signals_packet into struct remote_state Tom Tromey
2013-06-24 17:36   ` Pedro Alves
2013-06-27 20:13     ` Tom Tromey
2013-06-21 17:25 ` [PATCH 07/16] push last_pass_packet " Tom Tromey
2013-06-21 17:25 ` [PATCH 10/16] push last_sent_step " Tom Tromey
2013-06-21 17:25 ` [PATCH 14/16] move async_client_callback and async_client_context into remote_state Tom Tromey
2013-06-24 17:32   ` Pedro Alves
2013-06-24 18:44     ` Tom Tromey
2013-06-24 19:03       ` Pedro Alves
2013-06-21 17:25 ` [PATCH 16/16] move some static thread state " Tom Tromey
2013-06-24 17:33   ` Pedro Alves
2013-06-27 20:21     ` Tom Tromey
2013-06-21 17:25 ` [PATCH 06/16] push remote_traceframe_number into struct remote_state Tom Tromey
2013-06-21 17:25 ` [PATCH 01/16] use the libiberty crc code Tom Tromey
2013-06-24 17:24   ` Pedro Alves
2013-06-27 20:12     ` Tom Tromey
2013-06-21 17:25 ` [PATCH 09/16] push last_sent_signal into struct remote_state Tom Tromey
2013-06-21 17:25 ` [PATCH 04/16] push remote_desc " Tom Tromey
2013-06-24 17:25   ` Pedro Alves
2013-06-27 20:29     ` Tom Tromey
2013-06-28 16:43       ` [PATCH] Make file transfer commands work with all (native) targets. (was: Re: [PATCH 04/16] push remote_desc into struct remote_state) Pedro Alves
2013-06-28 17:40         ` [PATCH] Make file transfer commands work with all (native) targets Tom Tromey
2013-06-28 17:46         ` [PATCH] Make file transfer commands work with all (native) targets. (was: Re: [PATCH 04/16] push remote_desc into struct remote_state) Eli Zaretskii
2013-06-28 19:05           ` Pedro Alves [this message]
2013-06-28 19:35             ` [PATCH] Make file transfer commands work with all (native) targets Eli Zaretskii
2013-07-01 14:28               ` Tom Tromey
2013-07-01 16:34                 ` Pedro Alves
2013-07-01 16:41                 ` Eli Zaretskii
2013-07-01 16:44                   ` Pedro Alves
2013-06-21 17:25 ` [PATCH 15/16] move remote_stopped_by_watchpoint_p and remote_watch_data_address into remote_state Tom Tromey
2013-06-21 17:25 ` [PATCH 12/16] move use_threadinfo_query and use_threadextra_query into struct remote_state Tom Tromey
2013-06-21 17:25 ` [PATCH 13/16] move sizeof_pkt into remote_trace_find Tom Tromey
2013-06-24  1:45   ` Yao Qi
2013-06-24 14:54     ` Tom Tromey
2013-06-24 17:32   ` Pedro Alves
2013-06-21 17:25 ` [PATCH 11/16] move some statics from remote_read_qxfer into struct remote_state Tom Tromey
2013-06-24 17:25   ` Pedro Alves
2013-06-21 17:25 ` [PATCH 05/16] push general_thread and continue_thread " Tom Tromey
2013-06-21 17:25 ` [PATCH 03/16] Add new_remote_state Tom Tromey
2013-06-21 17:30 ` [PATCH 02/16] make remote_protocol_features "const" Tom Tromey
2013-06-24 18:35 ` [PATCH 00/16] clean up remote.c state Pedro Alves
2013-07-05  3:07 ` Yao Qi
2013-07-05 14:27   ` Pedro Alves
2013-08-14 17:53 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51CDD537.3040300@redhat.com \
    --to=palves@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox