From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43430 invoked by alias); 1 Nov 2019 19:31:18 -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 43422 invoked by uid 89); 1 Nov 2019 19:31:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1321, Being, our X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Nov 2019 19:31:16 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 42F7132CD0 for ; Fri, 1 Nov 2019 14:31:14 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id Qcdei6rdsHunhQcdeiZjkd; Fri, 01 Nov 2019 14:31:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XlE8EN173xsIgzD1kEtpDom1ccDeDPDQPiAptFgUGEo=; b=OeT14Z3XGIKYraCp0uCJHv34wU JaqoRYpi18IeG++RGPtQewfxfMvmOp8ntYLtZ8+W0MajOifWX8H+bsC0pHuMS5983lkv/K/ufIX1C rkBfqyK04T4pc9bHH5FdS25sN; Received: from 75-166-66-104.hlrn.qwest.net ([75.166.66.104]:59212 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iQcde-000aYa-0k; Fri, 01 Nov 2019 13:31:14 -0600 From: Tom Tromey To: Aaron Merey Cc: Tom Tromey , Christian Biesinger via gdb-patches , Christian Biesinger Subject: Re: [RFC PATCH] Support debuginfo and source file fetching via debuginfo server References: <20190820202809.25367-1-amerey@redhat.com> <87pnj6dl3k.fsf@tromey.com> Date: Fri, 01 Nov 2019 19:31:00 -0000 In-Reply-To: (Aaron Merey's message of "Mon, 28 Oct 2019 16:34:02 -0400") Message-ID: <87sgn71ji6.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-11/txt/msg00042.txt.bz2 Tom> The control-c question is a good one -- I'd also like to know the Tom> answer. Most things in gdb are interruptible this way. Aaron> We are now using the libcurl multi interface to fetch files over HTTP Aaron> and it is mostly non-blocking (although blocking can happen during Aaron> domain name resolution). However ctrl+c does not interrupt our symbol Aaron> downloading within GDB. This may be due to GDB's SIGINT handling, Aaron> which just sets a flag for the event loop when it is not safe to Aaron> throw an exception. Based on a comment in Aaron> gdb/event-top.c:handle_sigint(), symfile reading is one such region. Aaron> Also, we have an environment var $DEBUGINFOD_TIMEOUT that lets users Aaron> control how much time is spent attempting each download without having Aaron> to rely on ctrl+c. I think an environment variable may be too late. I realize gdb doesn't generally allow interrupting the reading of symbol tables. But, this case is a little different, in that the main thing happening is the download of the debug info. Being able to interrupt this would be good, because servers can wedge, download speeds can be low, etc. Also, maybe printing something if the download takes too long would be good to do. Tom