From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45660 invoked by alias); 6 Apr 2016 15:04:27 -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 45645 invoked by uid 89); 6 Apr 2016 15:04:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2401, claim, metal 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, 06 Apr 2016 15:04:24 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 6EAADED25F for ; Wed, 6 Apr 2016 15:04:23 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u36F4Mjl004494; Wed, 6 Apr 2016 11:04:22 -0400 Subject: Re: [commit] 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> <5703EE91.7040409@redhat.com> <20160406143413.GA2885@host1.jankratochvil.net> Cc: gdb-patches@sourceware.org, Gary Benson From: Pedro Alves Message-ID: <57052576.1070404@redhat.com> Date: Wed, 06 Apr 2016 15:04: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: <20160406143413.GA2885@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00128.txt.bz2 On 04/06/2016 03:34 PM, Jan Kratochvil wrote: > On Tue, 05 Apr 2016 18:57:53 +0200, Pedro Alves wrote: >> On 03/23/2016 09:15 PM, Jan Kratochvil wrote: >>> 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, > > > I never proposed any patch mentioning multiple versions which you claim now to > be a disadvantage of the patch of mine - that is exactly a straw man argument > case. No, it is not. I never said _you_ proposed a patch mentioning multiple versions. I said "If we followed that direction going forward". Thinking of how a patch impacts future direction is not a straw man, and must be part of the development and review process. The patch mentioning a gdbserver version opens a precedent. It'd be reasonable then for other cases to get treated the same way once that direction is set, and multiple mentions of versions would be what we'd get against some stubs. Thus, coupled with not all stubs being gdbserver, I think that patch would set up for the wrong direction, hence the push back. >> 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. > > That is technically the right approach but (I think) that does not work for > laypeople. But I also think laypeople do not use (at least not directly) GDB > anyway so trying to make GDB userfriendly is probably a vain attempt > I sometimes try to do. Making GDB more user friendly is definitely a good goal, and much appreciated. Thanks, Pedro Alves