From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103647 invoked by alias); 22 May 2018 12:27:07 -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 100656 invoked by uid 89); 22 May 2018 12:26:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*x:version, Hx-languages-length:2422, H*UA:version X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 May 2018 12:26:22 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4MCP9SZ063230 for ; Tue, 22 May 2018 08:26:21 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j4grnf33m-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 May 2018 08:26:20 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 May 2018 13:26:18 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 22 May 2018 13:26:15 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4MCQFSI19792110; Tue, 22 May 2018 12:26:15 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 05E3452049; Tue, 22 May 2018 12:16:15 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.77]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id E89FC52043; Tue, 22 May 2018 12:16:14 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id C96E7D804DB; Tue, 22 May 2018 14:26:14 +0200 (CEST) Subject: Re: [PATCH] Linux/gdbserver: Correctly handle narrow big-endian register transfers To: macro@mips.com (Maciej W. Rozycki) Date: Tue, 22 May 2018 12:48:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, arnez@linux.vnet.ibm.com (Andreas Arnez) In-Reply-To: from "Maciej W. Rozycki" at May 22, 2018 11:30:58 AM MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18052212-0020-0000-0000-0000041FEB9B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052212-0021-0000-0000-000042B52467 Message-Id: <20180522122614.C96E7D804DB@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-22_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805220145 X-SW-Source: 2018-05/txt/msg00540.txt.bz2 Maciej W. Rozycki wrote: > This fixes the problem for MIPS, however from my understanding of your > commit it will break s390x unless it is further adjusted in a > target-dependent manner. So my question is: does `ptrace' indeed place > 32-bit quantities transferred in bits 63:32 of the 64-bit integer data > quantity passed? > > If so, then would wrapping this into `#ifndef __s390x__' be OK with you > as it's s390x that appears to be an oddball here by representing the > same 32-bit integer data quantity differently between 32-bit and 64-bit > systems (i.e. you can't just cast `long' to `int')? > > I have no access to an s390x to verify this change. This has passed > regression testing with o32 and n64 targets with `gdbserver' strapped to > use PTRACE_PEEKUSR and PTRACE_POKEUSR requests across all registers. Well, my understanding of PTRACE_PEEKUSR and PTRACE_POKEUSR is that they are supposed to simulate access to a "user area", i.e. a data structure that holds per-process status, in word sized chunks. Now of course the Linux kernel doesn't actually maintain such a "user area", but for the purpose of those ptrace calls, it is supposed to pretend it does. So if we e.g. have some word-sized floating-point registers and a halfword size status register, the kernel would pretend they are stored in a struct like this: struct user_area { long fpr[16]; int fpc; }; and if you access this with PTRACE_PEEKUSR at offset offsetof(struct user_area, fpc) you get the 8 bytes at this offset. On a big-endian system, those correspond to getting the 4 bytes of fpc in the most-significant bytes, and some padding in the least-significant bytes. This is what gdbserver expects, and what the kernel ptrace logic (at least on s390x, I cannot say about others) implements: } else if (addr == (addr_t) &dummy->regs.fp_regs.fpc) { /* * floating point control reg. is in the thread structure */ tmp = child->thread.fpu.fpc; tmp <<= BITS_PER_LONG - 32; If this is implemented differently on mips, I guess gdbserver will have to handle this, but I don't really like an #ifdef here. Can't you move the special logic into platform-specific the_low_target.collect_ptrace_register and the_low_target.supply_ptrace_register calls instead? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com