From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RD7cBLGq+WEYNQAAWB0awg (envelope-from ) for ; Tue, 01 Feb 2022 16:48:33 -0500 Received: by simark.ca (Postfix, from userid 112) id 034ED1F3B4; Tue, 1 Feb 2022 16:48:32 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 67E771EDF0 for ; Tue, 1 Feb 2022 16:48:32 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9D350385840B for ; Tue, 1 Feb 2022 21:48:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D350385840B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643752111; bh=661KXeEv/pQiwJDqIP2TppvOiCnCshe6Z8mXY1G9sZc=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=wCCou0iu4N2I1KzsT589gHdy4LfZ5ou6eA8u0lFPCm+SvNfND8PlT4ipdQXpLAsGc a2yQTiZOmuDoQ5wXJTeL4B+SgHlMaSnAb1xyl8V4C/LONoYEY9kjnUVER5ZUzHEwkV yZ9n1UIPMIxUNZAfgWlv2MiaYMd3TzkVkeBBPxl0= Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 2956C3858C83 for ; Tue, 1 Feb 2022 21:48:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2956C3858C83 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 211KNS2x006229 for ; Tue, 1 Feb 2022 21:48:12 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dybuyh97k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 Feb 2022 21:48:12 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 211Lisd2021100 for ; Tue, 1 Feb 2022 21:48:10 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma01dal.us.ibm.com with ESMTP id 3dvw7br923-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 Feb 2022 21:48:10 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 211Lm85336831540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Feb 2022 21:48:08 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 33FBA124055; Tue, 1 Feb 2022 21:48:08 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B788912405E; Tue, 1 Feb 2022 21:48:07 +0000 (GMT) Received: from sig-9-65-238-104.ibm.com (unknown [9.65.238.104]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 1 Feb 2022 21:48:07 +0000 (GMT) Message-ID: <0f8ec5130c4f798083a52129138241e130f1ee7e.camel@vnet.ibm.com> Subject: RFC gdbserver and tdesc and powerpc (stuck on a gdbserver assert) To: gdb-patches@sourceware.org Date: Tue, 01 Feb 2022 15:48:07 -0600 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 5Ee8arjC14r4oE4zaJ_DsqITgySsXFYu X-Proofpoint-GUID: 5Ee8arjC14r4oE4zaJ_DsqITgySsXFYu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-01_10,2022-02-01_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=412 malwarescore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202010118 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: will schmidt via Gdb-patches Reply-To: will schmidt Cc: rogerio , Ulrich Weigand Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, I've been working on a target-description rework for powerpc, this is a continuation of work that Rogerio has posted rfc patches for sometime last year. I've run into a stumbling block with the init_target_desc code in gdbserver, and am not sure how to best proceed. gdbserver/tdesc.cc: init_target_desc(...) iterates through the provided features and populates the reg_defs structure. The code currently has an assert with a comment: /* Register number will increase (possibly with gaps) or be zero. */ gdb_assert (regnum == 0 || regnum >= tdesc->reg_defs.size ()); This trips on powerpc (with the WIP tdesc patch set), potentially in several locations, since our features contain registers that are intermixed across the ranges, so we end up with regnos that numerically belong earlier in the tdesc->reg_defs structure, but they belong in the features where they are. In particular; The Powerpc "core" features includes regnums 0-31 (gprs r0..r31), a gap, then 64-69 (PC,MSR,CR,LR,CTR,XER). The subsequent "fpu" feature fills in that gap as it includes regnums 32-63 (f0..f31), and 70 (fpscr). There may or may not be an issue with the subsequent altivec and vsx register sets, since we have some overlapping ranges there. I could split apart the features into smaller bits, but this would scramble the documented powerpc features descriptions (as seen in gdb.texinfo). I've tried just disabling the assert, but I'm not certain that is sufficient, I currently also see some partial transfer errors between gdb and gdbserver that i've not sorted out. Appreciate any thoughts on how I should proceed. Thanks -Will