From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33054 invoked by alias); 22 Feb 2016 16:51:11 -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 33032 invoked by uid 89); 22 Feb 2016 16:51: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,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:0500, simpler, computing X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 22 Feb 2016 16:51:08 +0000 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C1.99.32102.16C3BC65; Mon, 22 Feb 2016 17:50:41 +0100 (CET) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 22 Feb 2016 11:51:06 -0500 References: <1455910116-13237-1-git-send-email-antoine.tremblay@ericsson.com> <56C7796B.3030504@redhat.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Pedro Alves CC: Antoine Tremblay , , Subject: Re: [PATCH v3] Enable tracing of pseudo-registers on ARM In-Reply-To: <56C7796B.3030504@redhat.com> Date: Mon, 22 Feb 2016 16:51:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00659.txt.bz2 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 ? 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. 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)? And that it is set to use tdesc registers (so that gdbarch_remote_register_number maps to tdesc_remote_register). Thanks, Antoine