From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81457 invoked by alias); 24 Feb 2016 18:11:10 -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 81434 invoked by uid 89); 24 Feb 2016 18:11:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pointless, Hx-languages-length:1865 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, 24 Feb 2016 18:11:08 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id AD2F5627CB; Wed, 24 Feb 2016 18:11:07 +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 u1OIB6Lj017934; Wed, 24 Feb 2016 13:11:06 -0500 Message-ID: <56CDF23A.8000007@redhat.com> Date: Wed, 24 Feb 2016 18:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Antoine Tremblay CC: gdb-patches@sourceware.org, qiyaoltc@gmail.com Subject: Re: [PATCH v3] Enable tracing of pseudo-registers on ARM References: <1455910116-13237-1-git-send-email-antoine.tremblay@ericsson.com> <56C7796B.3030504@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00740.txt.bz2 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? And that it is set to use tdesc > registers (so that gdbarch_remote_register_number maps to > tdesc_remote_register). Thanks, Pedro Alves