From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46753 invoked by alias); 12 Aug 2015 13:58:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 46744 invoked by uid 89); 12 Aug 2015 13:58:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 12 Aug 2015 13:58:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id C10CC32B71B; Wed, 12 Aug 2015 13:58:52 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7CDwnCi003594; Wed, 12 Aug 2015 09:58:50 -0400 Message-ID: <55CB5119.9070504@redhat.com> Date: Wed, 12 Aug 2015 13:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gary Benson CC: Joel Brobecker , Doug Evans , Jan Kratochvil , gdb-patches , Sandra Loosemore , =?windows-1252?Q?Andr=E9_P=F6nitz?= , Paul Koning Subject: Re: [PATCH 0/2] Better handling of slow remote transfers References: <20150811195943.GC22245@adacore.com> <20150812094831.GD11096@blade.nx> <55CB1B8D.6010501@redhat.com> <20150812103831.GA12792@blade.nx> <55CB2DF8.2050506@redhat.com> <20150812123254.GA14726@blade.nx> <55CB4150.6090807@redhat.com> <20150812130248.GA15429@blade.nx> <55CB4B74.3070204@redhat.com> <20150812133825.GA25961@blade.nx> In-Reply-To: <20150812133825.GA25961@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00286.txt.bz2 On 08/12/2015 02:38 PM, Gary Benson wrote: > Pedro Alves wrote: >> On 08/12/2015 02:02 PM, Gary Benson wrote: >>>>>>>>> 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? >>> I was looking in getpkt_or_notif_sane_1, but I think maybe I misread >>> it. I'll get back to you on this... >> >> That's the very low level of RSP packets, which as you noted will >> have a reasonable cap. It sounds to me there's a loop somewhere in >> a higher layer that is missing a QUIT. E.g., we have quits >> in dwarf2read.c which allow interrupting reading big binaries, >> even if locally. So what is the higher level operation that >> gdb is doing when you try to interrupt, but can't? > > remote_hostio_pread. I'm trying to make remote_hostio_pread > interruptible. BFD is doing large remote_hostio_pread which > are resulting in large vFile:pread: packet responses. And what is BFD doing that ends up in those remote_hostio_pread calls? Reading the elf headers, parsing the symbol table, etc? Or maybe something else? GDB will usually cap the transfers to before they get to the lower layers. E.g., look for 4096 in memory_xfer_partial, target_read_alloc_1 and target_fileio_read_alloc_1. As this request is coming from the BFD side, we should probably make remote_hostio_pread also cap the size of the vFile:pread request. A reasonable number like a few KBs should not introduce any noticeable slow down. Thanks, Pedro Alves