From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87522 invoked by alias); 24 Jul 2015 13:59:28 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 87510 invoked by uid 89); 24 Jul 2015 13:59:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jul 2015 13:59:26 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1ZIdVS-0007At-VH from Sandra_Loosemore@mentor.com ; Fri, 24 Jul 2015 06:59:22 -0700 Received: from [IPv6:::1] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Fri, 24 Jul 2015 06:59:22 -0700 Message-ID: <55B2444C.106@codesourcery.com> Date: Fri, 24 Jul 2015 13:59:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gary Benson CC: "gdb@sourceware.org" Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target References: <55B1768E.9090309@codesourcery.com> <55B1A4FC.9010403@codesourcery.com> <20150724085244.GB22673@blade.nx> In-Reply-To: <20150724085244.GB22673@blade.nx> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00044.txt.bz2 On 07/24/2015 02:52 AM, Gary Benson wrote: > > A large part of the motivation for these patches was to automate as > much as possible so users did not have to tell GDB stuff it could > figure out itself. Rather than reverting (the nuclear option!) > how about we see if we can make GDB handle this. > > How were you debugging before these series went in? Without symbols? > If you'd started GDB with "file" and "set sysroot" commands to set up > your environment the whole remote-fetch should not have happened. I am passing the executable to GDB on the command line. The executable is linked with explicit -Wl,-dynamic-linker= and -Wl,-rpath options pointing to a sysroot that is NFS-mounted on the remote target at the same pathname as on the host system. (This is our normal automated test configuration here, BTW.... I was trying to investigate why mainline GDB testing now takes 12 hours versus 38 minutes for our last stable release, and quickly realized that GDB's current behavior is going to be totally unacceptable for interactive use as well.) The user documentation we at Mentor distribute with our toolchains that explains sysroots says that you only need to do "set sysroot" in the debugger if you are interested in debugging shared libraries or multi-threaded applications, *and* the remote sysroot pathname is not valid on the host system. Neither of these things applies to what I was trying to do. Plus, generally speaking, if you fail to do "set sysroot" in older GDB versions, application debugging still works even if there is a mismatch in the sysroot pathnames between host and target.... you just get some messages now and then about how GDB couldn't find some shared library symbols, and suggesting that you try "set sysroot". What I find particularly confusing is that continuing to main doesn't seem like a user action that requires information from the sysroot at all. I have not set any breakpoints in shared libraries, I'm not trying to backtrace through a library call, and I haven't requested that GDB stop on solib events. Why does GDB need to transfer these files from the target at all if the user is not interested in them? > I'll look into some combination of making the remote transfer > interruptable, and issuing a warning during slow transfers, to > see if something like that could work. Could you update the > manual to add the information that you would have like to have > found there? I'd rather that we fix GDB to "just work", as it used to do, rather than have to document workarounds for this breakage. -Sandra