From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26510 invoked by alias); 26 Jun 2013 17:11:50 -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 26500 invoked by uid 89); 26 Jun 2013 17:11:49 -0000 X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 17:11:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5QHBjes012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 13:11:46 -0400 Received: from psique (ovpn-113-175.phx2.redhat.com [10.3.113.175]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5QHBeKd013266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 13:11:42 -0400 From: Sergio Durigan Junior To: Tom Tromey Cc: Joel Brobecker , gdb-patches@sourceware.org, Jan Kratochvil , Pedro Alves Subject: Re: [commit] Improved linker-debugger interface References: <20130516144340.GA2105@blade.nx> <20130604133819.GA25892@blade.nx> <20130625205350.GA28973@adacore.com> <87hagkrih3.fsf@fleche.redhat.com> X-URL: http://www.redhat.com Date: Wed, 26 Jun 2013 17:23:00 -0000 In-Reply-To: <87hagkrih3.fsf@fleche.redhat.com> (Tom Tromey's message of "Wed, 26 Jun 2013 09:37:28 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00784.txt.bz2 On Wednesday, June 26 2013, Tom Tromey wrote: > It seems to me that we could make the warning more verbose and have it > request that users file a bug report; and it could include a little > explanation, plus some text to report. Like: > > warning: Probes-based dynamic linker interface failed: > Unknown numeric token ... > This means there is a bug, either in gdb or elsewhere in the > toolchain. Please report it to the gdb bugzilla, along with > this information: > Arch: Whatever > Probe name: ... > Argument number: ... > Argument text: ... > > Being extra wordy is a bit of a pain, maybe, since presumably users will > see it often. OTOH, it's a "shouldn't happen" scenario where gdb has > lots of information already... Sounds good to me, but... > Also, I wonder why we're trying to use the probes on a platform to which > the gdb side hasn't been ported. Are we just optimistically trying to > parse the assembly operands here? That's a relevant question. GDB has a generic asm parser (implemented in stap-probe.c), which makes use of specific target-dep functions/variables to correctly handle the idiosyncrasies of each type of asm. So far, we have support for x86, x86_64, PPC, PPC64, ARM, and a pending patch for IA-64. However, there must be more architectures where we will need to implement it. The pre-requisite I am/was using is: if systemtap-sdt-devel is installable on the system, then GDB needs to support SDT probes. Unfortunately I failed to check IA-64, but that is hopefully fixed now. OTOH, if the user successfuly installs on her system, then GDB should at least be prepared to avoid trying to parse something it doesn't fully understand. What could be done is to check gdbarch_stap_is_single_operand_p. This is a mandatory function that needs to be set by the target. If it doesn't exist, then we know that the target lacks SDT support. Before I work on a patch, I'd like to know what you think. Thanks, -- Sergio