From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121881 invoked by alias); 24 Feb 2016 18:21:06 -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 121696 invoked by uid 89); 24 Feb 2016 18:21:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2663, higher-level, higherlevel X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Feb 2016 18:21:02 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id 5A59A40000; Wed, 24 Feb 2016 19:21:54 +0100 (CET) Received: from [192.168.13.108] (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by hogfather.0x04.net (Postfix) with ESMTPSA id 0AD24580100; Wed, 24 Feb 2016 19:21:00 +0100 (CET) Subject: Re: [PATCH v3] Enable tracing of pseudo-registers on ARM To: Pedro Alves , Antoine Tremblay References: <1455910116-13237-1-git-send-email-antoine.tremblay@ericsson.com> <56C7796B.3030504@redhat.com> <56CDF23A.8000007@redhat.com> Cc: gdb-patches@sourceware.org, qiyaoltc@gmail.com From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56CDF48B.5040008@0x04.net> Date: Wed, 24 Feb 2016 18:21: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: <56CDF23A.8000007@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00742.txt.bz2 On 24/02/16 19:11, Pedro Alves wrote: > On 02/22/2016 04:51 PM, Antoine Tremblay wrote: >> >> Pedro Alves writes: >> >>> Hmm, seems to me that gdb raw -> target raw mapping should be >>> either here, or perhaps even in ax_reg / ax_reg_mask? >>> >>> Consider the case of an expression requiring the collection of >>> a _raw_ register, thus not even reaching here. Looking at >>> ax-gdb.c/ax-general.c I don't see where is anything mapping gdb raw numbers >>> to remote/tdesc numbers? So how does _that_ work? Are the register masks that gdb >>> is computing actually wrong for the target, and things just happen >>> to work because gdbserver ignores them and always collects all registers? >>> >> >> Is there a good reason gdbserver actually ignores that ? > > I don't recall any, other than collecting everything is expedient > and good enough... > >> >> It seems all the code is there for it to consider it on gdb's >> side. encode_actions, stringify_collection_list etc... The only thing >> missing seems to be gdbserver interpretation of the R action. > > Right. Obviously you'd need to consider how to represent the > partial register set in the trace frame as well. Just marking > some registers as unavailable while still crafting a whole register > block in the trace buffer is pointless, obviously. > >> >> While looking at fixing this for all the archs involved it would be >> much simpler to test if gdbserver would make use of it. >> >> As it is now, I'm concerned that calling gdbarch_remote_register_number >> in ax_reg, ax_mask_reg could break things if the arch already considers >> the gdb raw -> target raw mapping like s390 and x86 do already (I'm not >> 100% sure the mapping is already ok)? > > WDTM? Where do they do this already? FWIW, I failed to look at the numbering used when I wrote the x86 and s390 ax functions, so they're most likely wrong (I just copied the regnum computation logic from pseudo_read/write, which uses gdb numbers). s390 hasn't landed yet, so it's only x86 that you'd have to fix now (and mips, I think, but that doesn't support tracepoints yet...). Testing this is possible if you write some conditions that involve reading pseudo-registers (since ax_pseudo_register_push_stack will be called), the problem is that I only implemented ax_pseudo_register_collect for x86... Are you going to make some higher-level patch that will magically fix it for my s390 patch, or do I have to fix that on my own? > > > And that it is set to use tdesc >> registers (so that gdbarch_remote_register_number maps to >> tdesc_remote_register). > > Thanks, > Pedro Alves >