Re: [PATCH 0/2] Better handling of slow remote transfers

[Gary Benson <gbenson@redhat.com>]

Joel Brobecker wrote:
> Sandra Loosemore wrote:
> > It actually looks to me like we are not any closer to having this
> > resolved than we were at the beginning of the week.  Gary's last
> > patch for ^C handling didn't work for me and he said he is out of
> > ideas.  I am willing to try out patches, but I'm really swamped
> > with other tasks right now as well as being totally unfamiliar
> > with the internals of this code, so it's not reasonable to think I
> > could fix this myself in time for the 7.10 release.  And AFAIK
> > nobody else is working on this either.  :-(
> 
> I think the situation is a little better than you describe.  As far
> as I understand, there is one patch that changes the default for
> sysroot back to ""; it is expected to restore the current behavior
> in your case, but at the same time introduces a change in behavior
> in one specific situation where someone is debugging remotely
> without providing the executable to GDB (either through the
> command-line or using the "file" command). The change of behavior
> and how to control it is what's being debated at the moment, and is
> why you're still seeing the issue.

Just to clarify, the default sysroot of "target:" has two purposes:

 1. It allows GDB to locate and access binaries on remote targets
    without having to be told where they are.

 2. It allows GDB to locate and access binaries on native targets
    when the inferior is running in a container.

Resetting the default sysroot to "" disables both cases.  The second
is arguably more important, because without it users can attach to a
local process (with, e.g., gdb -p PID) but GDB can end up loading the
wrong symbols if binaries with the same paths exist both within the
container and on the host machine.

> Parallel to that, my understanding of the situation is that there is
> a secondary issue of not being able interrupt a file transfer. That
> is what you've been testing so far, I believe. Lack of success so
> far is a little fustrating for everyone, I'm sure. But I am still
> wondering whether you should even be in the situation where you need
> to interrupt in the first place.
> 
> That's why, to me, the first discussion has a little more weight.
> We'll want to figure out the mystery in the secondary issue, but
> if we can find the right approach in the first discussion for 7.10,
> that would buy us some extra time in terms of being able to interrupt
> file transfers.

It seems to me that being able to interrupt file transfers is polish.
With the warning patch alone, users will see the warning and the hint
about how to restore the previous default, which they can apply and
continue as before.  If they have to wait out a transfer then it will
presumably only be once.  I know some people use GDB on systems with
5,000+ shared libraries, and others use GDB on slow serial links, but
I don't think anybody combines these cases.

So, would the warning+hint patch alone be enough?

FWIW the reason I am out of ideas for making transfers interruptible
is that both QUIT patches I supplied allow me to interrupt transfers.
Something is obviously different on Sandra's setup to mine, but I
don't know what, and without a reproducer I'm just stabbing in the
dark.

Thanks,
Gary

-- 
http://gbenson.net/