From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113305 invoked by alias); 5 Apr 2016 16:58:04 -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 112856 invoked by uid 89); 5 Apr 2016 16:58:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=1517, 151,7, largely, servers 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; Tue, 05 Apr 2016 16:57:56 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A95963142 for ; Tue, 5 Apr 2016 16:57:55 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u35GvrA6013297; Tue, 5 Apr 2016 12:57:54 -0400 Subject: Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read To: Jan Kratochvil References: <20160319201842.GA16540@host1.jankratochvil.net> <56F13963.9040204@redhat.com> <20160322131604.GA24312@host1.jankratochvil.net> <56F14F1E.5010606@redhat.com> <20160323211547.GA17400@host1.jankratochvil.net> Cc: gdb-patches@sourceware.org, Gary Benson From: Pedro Alves Message-ID: <5703EE91.7040409@redhat.com> Date: Tue, 05 Apr 2016 16:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160323211547.GA17400@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00091.txt.bz2 On 03/23/2016 09:15 PM, Jan Kratochvil wrote: > On Tue, 22 Mar 2016 14:56:46 +0100, Pedro Alves wrote: >> - I think the important points are: >> >> - The user did not specify the executable manually. >> >> - The target/server does not support automatic executable >> retrieval. >> >> - I see that at least the following choices to correct the situation: >> >> #1 - Upgrade server to some version that supports automatic automatic >> executable retrieval. >> >> #2 - Hack on stub/server yourself to add support for automatic >> executable retrieval, if possible on the target. >> >> #3 - Use the "file" command. >> >> If you're connecting with a new gdb to an older gdbserver, it usually >> means that installing a newer gdbserver is more than a couple >> seconds work, and may not even be possible. I think #3 will be the >> path most often taken. >> >> So I'd suggest: >> >> warning: No executable has been specified and target does not support >> determining executable automatically. Try using the \"file\" command. >> >> Seeing this, users that can hack on a remote stub will probably >> realize that there's now some way for gdb to automatically retrieve >> the executable. We don't need to expose implementation details for those >> users; they'll be savvy enough to find the necessary info in the RSP >> manual. For other users, talking about implementation details may >> largely be noise. > > I still do not see there any hint that a newer FSF gdbserver would also fix the > problem. That's because I don't think it's a good approach. If we followed that direction going forward, we'd end up with: warning: Remote gdbserver does not support determining executable automatically. FSF gdbserver version 7.10 or later would support that. warning: Remote gdbserver does not support foo. FSF gdbserver version 6.5 or later would support that. warning: Remote gdbserver does not support bar. FSF gdbserver version 6.8 or later would support that. Old version numbers shown on purpose -- that's what 7.10 will feel like in a couple years. I think it's not a good idea to show version numbers, nor am I convinced mentioning gdbserver is a good idea either. There's bare metal targets, and then there's also other servers like qemu, Valgrind, RR, etc. Sorry for pushing back, but I think warnings should be centered on features, not tools and versions. > Attached patch prints messages as: > > Remote debugging using :1234 > warning: Remote gdbserver does not support determining executable automatically. > FSF gdbserver version 7.10 or later would support that. > warning: No executable has been specified and target does not support > determining executable automatically. Try using the "file" command. > warning: Could not load vsyscall page because no executable was specified > 0x00007ffff7ddcc80 in ?? () > (gdb) _ > > diff --git a/gdb/exec.c b/gdb/exec.c > index 90811c0..a10ab9b 100644 > --- a/gdb/exec.c > +++ b/gdb/exec.c > @@ -151,7 +151,13 @@ exec_file_locate_attach (int pid, int from_tty) > /* Try to determine a filename from the process itself. */ > exec_file = target_pid_to_exec_file (pid); > if (exec_file == NULL) > - return; > + { > + warning (_("No executable has been specified and target does not " > + "support\n" > + "determining executable automatically. " > + "Try using the \"file\" command.")); > + return; > + } This bit is OK. > diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c > index 8eb5176..79739a6 100644 > --- a/gdb/symfile-mem.c > +++ b/gdb/symfile-mem.c > @@ -214,8 +214,7 @@ add_vsyscall_page (struct target_ops *target, int from_tty) > format should fix this. */ > { > warning (_("Could not load vsyscall page " > - "because no executable was specified\n" > - "try using the \"file\" command first.")); > + "because no executable was specified")); > return; This bit is OK. Please split them out and push them. Please don't push the other hunks in. I think we'll need more discussion on those and I'd rather if we found some other way to address this, if we must. Thanks, Pedro Alves