From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65698 invoked by alias); 22 Mar 2016 13:56:51 -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 65684 invoked by uid 89); 22 Mar 2016 13:56:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Upgrade, savvy, Random, noise 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, 22 Mar 2016 13:56:49 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 689877F6A6 for ; Tue, 22 Mar 2016 13:56:48 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MDulJq018998; Tue, 22 Mar 2016 09:56:47 -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> Cc: gdb-patches@sourceware.org, Gary Benson From: Pedro Alves Message-ID: <56F14F1E.5010606@redhat.com> Date: Tue, 22 Mar 2016 13:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160322131604.GA24312@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00459.txt.bz2 On 03/22/2016 01:16 PM, Jan Kratochvil wrote: > On Tue, 22 Mar 2016 13:24:03 +0100, Pedro Alves wrote: >> On 03/19/2016 08:18 PM, Jan Kratochvil wrote: >>> if (packet_support (PACKET_qXfer_exec_file) != PACKET_ENABLE) >>> - return NULL; >>> + { >>> + warning (_("No executable has been specified (see the \"file\" command) " >>> + "and remote gdbserver does not " >>> + "support packet \"qXfer:exec-file:read\"" >>> + " - please use FSF gdbserver version 7.10 or later.")); >>> + return NULL; >>> + } >> >> I think this will print the warning after connecting to any >> random stub, not just gdbserver. Won't it be confusing >> to suggest FSF gdbserver in that case? > > (1) I think this message can only appear during a mistake. Is it right? > In fact this is my primary concern with this patch. > In such case I find any info better than no info. > > (2) Still it may suggest they could for example implement qXfer:exec-file:read > in their gdbserver stub if appropriate. I believe that people who use custom > gdbserver stub are more aware of how to fix it than normal > (=desktop/enterprise) OS developers who just try to debug some programs. > > (3) Do you have a better idea? One could add "if approproate" in that > message but I find that excessive. One could detect FSF gdbserver > (if possible, I do not think it is, BTW it could be good to identify > variant+version of gdbserver over the protocol) but then still if it either is > or is not a FSF gdbserver that message may be relevant in some cases. > - It's usually a mistake, though you can genuinely not have a binary available. Not "only", but "usually". - Random stubs may not know at all the executable that is running -- the remote end is often just bare metal raw memory, no concept of elf, etc. So it's not just a matter of implementing a packet - more tooling might and I suspect will, be necessary. OTOH, there are OSs where it's just not possible, by design, to retrieve the name of the executable a process is running, like OpenBSD (I find it odd not to allow a ptracer access to that, but, alas). - 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. Thinking of local/remote parity (and perhaps some day using gdbserver for local debugging), that text is also generic enough that it could be emitted by common code instead. WDYT? Thanks, Pedro Alves