From: Pedro Alves <palves@redhat.com>
To: Gary Benson <gbenson@redhat.com>
Cc: "Joel Brobecker" <brobecker@adacore.com>,
"Doug Evans" <dje@google.com>,
"Jan Kratochvil" <jan.kratochvil@redhat.com>,
gdb-patches <gdb-patches@sourceware.org>,
"Sandra Loosemore" <sandra@codesourcery.com>,
"André Pönitz" <apoenitz@t-online.de>,
"Paul Koning" <Paul_Koning@dell.com>
Subject: Re: [PATCH 0/2] Better handling of slow remote transfers
Date: Wed, 12 Aug 2015 12:51:00 -0000 [thread overview]
Message-ID: <55CB4150.6090807@redhat.com> (raw)
In-Reply-To: <20150812123254.GA14726@blade.nx>
On 08/12/2015 01:32 PM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 08/12/2015 11:38 AM, Gary Benson wrote:
>>> It seems like you're saying this series is a big change, but it's
>>> really not: the core of it is that little snippet of logic, which
>>> is easy enough to reason about:
>>>
>>> IF target filesystem is remote
>>> AND auto_target_prefix is enabled
>>> AND no sysroot is set
>>> AND (we're looking for an executable
>>> OR we're looking for a solib loaded by a target-prefixed executable):
>>> Prefix the filename with "target:"
>>>
>>
>> IIUC, it still auto fetches the executable and then the solibs from
>> the target by default (e.g., after "attach"), so still subject to
>> lack of interruptibility?
>
> Yes and no. It will fetch the executable from the remote iff one has
> not been otherwise specified (i.e. by "file", or on the command line).
> It will *only* fetch libraries from the remote if the parent executable
> has a target prefix. So:
>
> (gdb) file a.out
> (gdb) target remote :9999
>
> - exec_filename is "a.out"
> - exec_filename has no "target:" prefix
> - "target:" prefix is NOT applied to shared libraries
> - solib paths end up as "/path/to/libsolib.so.1"
> - solibs are NOT fetched over RSP
>
But to me it looks like GDB _should_ retrieve the libraries
out of the target in this case. You'll usually have a local copy
of the executable, because you just compiled it, but not of
the shared libraries. It seems to me we're only considering
this option because we didn't make transfers interruptible?
>> I was only OK with trying to make transfers interruptible in the
>> branch assuming it was something non-invasive, like a missing QUIT
>> here and there.
>
> No, gdbserver sends the data in PBUFSIZ chunks, but GDB reads the
> data a character at a time.
Can you expand on this? What code is it that reads the data a
character at a time? What data is gdb getting at when it does that?
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-08-12 12:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 17:22 Doug Evans
2015-08-11 18:55 ` Jan Kratochvil
2015-08-11 19:44 ` Doug Evans
2015-08-11 19:59 ` Joel Brobecker
2015-08-12 9:48 ` Gary Benson
2015-08-12 10:10 ` Pedro Alves
2015-08-12 10:38 ` Gary Benson
2015-08-12 11:29 ` Pedro Alves
2015-08-12 12:32 ` Gary Benson
2015-08-12 12:51 ` Pedro Alves [this message]
2015-08-12 13:02 ` Gary Benson
2015-08-12 13:34 ` Pedro Alves
2015-08-12 13:38 ` Gary Benson
2015-08-12 13:44 ` Gary Benson
2015-08-12 13:58 ` Pedro Alves
2015-08-12 14:44 ` Pedro Alves
2015-08-12 15:08 ` Gary Benson
2015-08-12 15:31 ` Pedro Alves
2015-08-12 15:45 ` Gary Benson
2015-08-12 13:29 ` Gary Benson
2015-08-14 18:26 ` Joel Brobecker
2015-08-14 22:26 ` Sandra Loosemore
2015-08-16 18:49 ` Joel Brobecker
[not found] ` <20150817085310.GC25320@blade.nx>
2015-08-17 14:26 ` Sandra Loosemore
2015-08-18 9:59 ` Gary Benson
2015-08-18 16:52 ` Sandra Loosemore
2015-08-19 1:27 ` Pedro Alves
2015-08-19 10:41 ` [PATCH] Prelimit number of bytes to read in "vFile:pread:" Gary Benson
2015-08-19 10:51 ` Gary Benson
2015-08-19 12:00 ` Pedro Alves
2015-08-19 16:43 ` Sandra Loosemore
2015-08-19 17:21 ` Gary Benson
2015-08-19 21:14 ` Sandra Loosemore
2015-08-20 14:48 ` Pedro Alves
2015-08-20 15:52 ` Pedro Alves
2015-08-20 17:00 ` Pedro Alves
2015-08-20 18:23 ` Sandra Loosemore
2015-08-21 14:52 ` [PATCH] remote: allow aborting long operations (e.g., file transfers) (Re: [PATCH] Prelimit number of bytes to read in "vFile:pread:") Pedro Alves
2015-08-21 17:12 ` Sandra Loosemore
2015-08-21 17:27 ` Pedro Alves
2015-08-25 10:57 ` Pedro Alves
2015-08-25 15:36 ` Pedro Alves
2015-08-25 20:19 ` GDB 7.10 release tentative date: Fri Aug 28 (was: "Re: [PATCH] remote: allow aborting long operations (e.g., file transfers) (Re: [PATCH] Prelimit number of bytes to read in "vFile:pread:")") Joel Brobecker
2015-08-24 8:45 ` [PATCH] remote: allow aborting long operations (e.g., file transfers) (Re: [PATCH] Prelimit number of bytes to read in "vFile:pread:") Gary Benson
2015-08-19 11:44 ` [PATCH] Prelimit number of bytes to read in "vFile:pread:" Pedro Alves
2015-08-19 13:07 ` [pushed] " Gary Benson
2015-08-19 13:42 ` [PATCH 0/2] Better handling of slow remote transfers Gary Benson
2015-08-20 14:46 ` Pedro Alves
2015-08-20 18:01 ` Gary Benson
2015-08-21 9:34 ` [pushed] Add readahead cache to gdb's vFile:pread (Re: [PATCH 0/2] Better handling of slow remote transfers) Pedro Alves
2015-08-11 20:00 ` [PATCH 0/2] Better handling of slow remote transfers Jan Kratochvil
2015-08-12 10:05 ` Pedro Alves
-- strict thread matches above, loose matches on Subject: below --
2015-08-05 15:28 Gary Benson
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=55CB4150.6090807@redhat.com \
--to=palves@redhat.com \
--cc=Paul_Koning@dell.com \
--cc=apoenitz@t-online.de \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=sandra@codesourcery.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