From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106350 invoked by alias); 15 Feb 2016 10:27:37 -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 106332 invoked by uid 89); 15 Feb 2016 10:27:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1956, quantities, agent, our X-HELO: mail-pf0-f193.google.com Received: from mail-pf0-f193.google.com (HELO mail-pf0-f193.google.com) (209.85.192.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 15 Feb 2016 10:27:35 +0000 Received: by mail-pf0-f193.google.com with SMTP id c10so7349874pfc.0 for ; Mon, 15 Feb 2016 02:27:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=DhBuGPQQwV7GiWYhR/pPNiJiifOrDfwMFjpI+TOeEK0=; b=ChUbpHSSHHVMVY9+lP4bAJIpCPiBYZNJTK0Ymo7FerB5jLuh3Fok5kxDzhFeWYhBev iAJx1LwsXv5KjkqHEAS5l1S1tsygSyWrgNOeUaPAEHu/+IjpwPLhs2uj9JLLemesL68t BtuW2MP63CfKl0c6XvQCFpMhqI7yZ9YEQfYcsYzPuE7o5FGSqe1ecSuldI9BSmv5S1lW 9pBIjdhPDJuH6Vx+uIshMXcUrWCRbqPTN3TapB112oiZ6/l+HGULV+o0qNchkBvKRX84 2gwg6BQ/jaZr0SD1O14iDr+qtz6eBKSrAk7ohwcfPjarcrU/K0cNg7a9Z4gnWclVQFa3 3H+w== X-Gm-Message-State: AG10YOQCqiL4cxJhBJ4p7XPc2u95kz6SQpT9v+So3R5K7pjqQT8k4VILddGfTLe5A3cgig== X-Received: by 10.98.64.83 with SMTP id n80mr22227347pfa.149.1455532054028; Mon, 15 Feb 2016 02:27:34 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id o17sm37424824pfj.50.2016.02.15.02.27.31 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 15 Feb 2016 02:27:33 -0800 (PST) From: Yao Qi To: Marcin =?utf-8?Q?Ko=C5=9Bcielnicki?= Cc: Yao Qi , Antoine Tremblay , gdb-patches@sourceware.org Subject: Re: [PATCH 3/4] Enable tracing of pseudo-registers on ARM References: <1452188697-23870-1-git-send-email-antoine.tremblay@ericsson.com> <1452188697-23870-4-git-send-email-antoine.tremblay@ericsson.com> <86egcineq0.fsf@gmail.com> <56BE002F.7050305@0x04.net> Date: Mon, 15 Feb 2016 10:27:00 -0000 In-Reply-To: <56BE002F.7050305@0x04.net> ("Marcin \=\?utf-8\?Q\?Ko\=C5\=9Bcielni\?\= \=\?utf-8\?Q\?cki\=22's\?\= message of "Fri, 12 Feb 2016 16:54:23 +0100") Message-ID: <86egcee0a6.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00457.txt.bz2 Marcin Ko=C5=9Bcielnicki writes: > I'd like to point out that this testcase is near-useless for testing > ax_pseudo_register_collect or pseudo_register_to_register at the > moment - while gdb computes a mask of what registers need to be > collected, gdbserver just ignores it and collects all registers if any > register at all is to be collected. In turn, gdb allows you to > display the state of all registers, even ones not included in the > mask. In fact, the tfile-avx.exp test passes just fine if you change > it to collect any unrelated register. My commit with > ax_pseudo_register_collect only made it work because gdb needs to have > that function return success, the actual returned mask could just as > well be wrong... The usefulness I can think of is that GDB can check whether the pseudo register exists to collect. User may want to collect Q registers, but they don't exist on the target. > > The other hook, pseudo_register_push_stack, is much easier to test -=20 > it's invoked when a pseudo is used in an actual agent expression, > eg. if you use it in a tracepoint condition, or as part of the address > of collected memory area. However, it cannot be used on SIMD > registers (at least on x86, I don't know much about arm), as they > don't fit in an ULONGEST... The same issue on both arm and aarch64, AFAIK. > > Matter of fact, our support for >64-bit quantities in tracepoints is > very poor at the moment - they can only be collected wholesale when > they're single registers or contig memory areas. Use in expressions > is out (if you happen to have something interesting in low 32 bits of > a vector reg, sorry). Likewise, stiching them together with > DW_op_piece (or whatever that was called) also fails (see > https://sourceware.org/bugzilla/show_bug.cgi?id=3D17015). We could > definitely use some improvement there... Yeah, agreed. --=20 Yao (=E9=BD=90=E5=B0=A7)