From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11499 invoked by alias); 4 Dec 2014 13:39: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 11488 invoked by uid 89); 4 Dec 2014 13:39:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Thu, 04 Dec 2014 13:39:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB4DdgqP027107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 4 Dec 2014 08:39:42 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sB4Ddegf007355; Thu, 4 Dec 2014 08:39:41 -0500 Message-ID: <5480641C.6050004@redhat.com> Date: Thu, 04 Dec 2014 13:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andreas Arnez CC: gdb-patches@sourceware.org, Ulrich Weigand Subject: Re: [PATCH 2/2] S390: Fix gdbserver support for TDB References: <1417002962-3424-1-git-send-email-arnez@linux.vnet.ibm.com> <1417002962-3424-3-git-send-email-arnez@linux.vnet.ibm.com> <87iohvp77u.fsf@br87z6lw.de.ibm.com> <547DD8C2.9000403@redhat.com> <8761dtq2rx.fsf@br87z6lw.de.ibm.com> In-Reply-To: <8761dtq2rx.fsf@br87z6lw.de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00090.txt.bz2 On 12/02/2014 07:18 PM, Andreas Arnez wrote: > On Tue, Dec 02 2014, Pedro Alves wrote: > >> On 12/01/2014 06:15 PM, Andreas Arnez wrote: >> >>> But after a quick grep through the Linux kernel it seems that there are >>> currently only two regsets for which ENODATA can be returned: the TDB on >>> S390 and the iWMMXt state on ARM. >> >> I've pushed the PowerPC transactional memory ptrace support toward modeling >> from s390, and the current patches (iterating under review) will return >> ENODATA too, but for the exact same scenario, so sounds like we'll be >> good there too. >> >>> diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c >>> index 8b72523..42dd521 100644 >>> --- a/gdb/gdbserver/linux-arm-low.c >>> +++ b/gdb/gdbserver/linux-arm-low.c >>> @@ -199,6 +199,13 @@ arm_store_wmmxregset (struct regcache *regcache, const void *buf) >>> if (!(arm_hwcap & HWCAP_IWMMXT)) >>> return; >> >> What are the conditions the ARM kernel checks to return >> ENODATA for this regset? I'd assume that it'd be the case of >> the machine not really supporting iwmmxt, and thus the check >> above already catching this. > > Someone with more ARM background should probably answer this, but > according to elf_set_personality in arch/arm/kernel/elf.c it seems that > ENODATA is also returned if the binary is neither EABI nor softfloat, > even if HWCAP_IWMXXT is set. Looks like you're right. >> Doesn't this mean a write attempt to such a read-only regset "succeeds" >> silently instead of erroring? >> >> Does the test exercise this? How does GDB/native behave? > > Good point. Both gdbserver and GDB silently "succeed". I did not > consider this a significant issue so far... Any suggestions how to > improve this behavior? Hmm, thinking further, I think the main issue is that gdbserver may get a single G packet to write the whole register buffer to the target, and it'll get that whether the user explicitly tried to change one of the read-only registers, or any other regular register. I think we'd have to augment the G packet with a way that says "these values are don't care, I'm not actually writing to these registers". The read/'g' packet uses 'x' for unavailable registers, maybe we could reuse that for writes/'G', something like "G 00112233xxxx0022", meaning the registers at the offsets where we have 'x's shouldn't be written. Anyway, if GDB behaves the same, let's not worry about this now. Thanks, Pedro Alves