From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id BFF38385800B for ; Mon, 5 Jul 2021 11:04:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFF38385800B Received: by mail-ed1-x534.google.com with SMTP id t3so23173891edt.12 for ; Mon, 05 Jul 2021 04:04:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5dj2xEGHeBpQncQYWOSlKeY5d9e6NnVEyq6luagMKi8=; b=nZAhEaZPHpT94GTKWT19mD7Per8xpKF6V6go8s6hNSBWWqF4dn2jqx9IelxW4vLa0x KHAPy6Ha5Vsw9mxtZrr3wA39zaGVJxZfL9TMirbC2GITj2dNAL3931jcKauY827gZ3Z4 zIQTW9X2ptOL2tl49+a6d1OIi8pvPmYOuJxW1HrD9v3hodpiPWdK6hFJtWJNG/iW1Cg+ NXm3jFRErhyAHafRp3eiZ8Tuw14ktC/tlESQ0ovL9akbfHa1wMSDSv3byhVmHZecHOBW Gf9Ht5IYQ702Mw4xWQuoCSb0JCsOb14rDFyJR5fBWte+RWV0DAQBozyQw5CtXoVj+wPh vrtQ== X-Gm-Message-State: AOAM530nyr6Bh+dmVt33BMQ2ymbBcZ749lnBKzWDYqYJPQO8vIS7pPxd fM9SQUtgCYwvaGcVWTR1dJs35rJnD8j71ixMrglBwQ== X-Google-Smtp-Source: ABdhPJxbYbSv+u289tEDmsOs+Xhr2IrCKWecPC1nqIjdJQ1JWloP24o+eJaBtk3X7tIrbTJkgAMAvPOZQz93eTkfxVc= X-Received: by 2002:a50:99cf:: with SMTP id n15mr15853159edb.146.1625483077852; Mon, 05 Jul 2021 04:04:37 -0700 (PDT) MIME-Version: 1.0 References: <6c749877-8805-0373-3071-aa55d501d2ab@linaro.org> In-Reply-To: <6c749877-8805-0373-3071-aa55d501d2ab@linaro.org> From: Peter Maydell Date: Mon, 5 Jul 2021 12:03:59 +0100 Message-ID: Subject: Re: [GDB][PATCH] arm: Add support for mve vector predicate status and control register (vpr) and pseudo register p0. To: Luis Machado Cc: Srinath Parvathaneni , gdb-patches@sourceware.org, Alan Hayward Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 05 Jul 2021 11:04:40 -0000 On Mon, 5 Jul 2021 at 11:39, Luis Machado wrote: > > Hi Srinath, > > > On 7/2/21 5:47 AM, Srinath Parvathaneni via Gdb-patches wrote: > > Hello, > > > > This patch add support for mve vector predication status and control register (vpr) and pseudo register p0. > > Pseudo register p0 is the least significant bits of vpr and can be accessed as $p0, $vpr.p0. > > For more information about the register please refer to [1]. > > > > [1] https://developer.arm.com/documentation/ddi0553/bn > > @@ -83,6 +84,7 @@ enum arm_m_profile_type { > > ARM_M_TYPE_M_PROFILE, > > ARM_M_TYPE_VFP_D16, > > ARM_M_TYPE_WITH_FPA, > > + ARM_M_TYPE_MVE, > > ARM_M_TYPE_INVALID > > }; Not in this patch, but since I see it going by, what is "M_TYPE_WITH_FPA" ? https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/features/arm/arm-m-profile-with-fpa.xml;h=fceeaea71771f12754bb19640aa951ddd8e18452;hb=HEAD seems to think it is a combination of an M-profile CPU with the ancient FPA floating point unit registers (for the hardware that preceded VFP). This doesn't correspond to any actual hardware, because M-profile FP is always VFP. > > @@ -9270,7 +9368,9 @@ arm_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) > > does not support that. */ > > feature = tdesc_find_feature (tdesc, > > "org.gnu.gdb.arm.neon"); > > - if (feature != NULL) > > + /* If we have VFP and no NEON, check for MVE. MVE uses NEON pseudos > > + q0 to q7. */ Why "if we have VFP and no NEON" ? Integer-only MVE is a permitted implementation, in which case there is no requirement to implement the "FP extension". > > + if (feature != NULL || is_mve) > > { > > /* NEON requires 32 double-precision registers. */ > > if (i != 32) This change tries to use this code path for MVE, but this condition here reads /* NEON requires 32 double-precision registers. */ if (i != 32) return NULL; which will always fail for MVE, because MVE has only registers D0..D15, not D16..D31. It looks like quite a lot of the code assumes that have_neon_pseudos implies "have Q0..Q15", so setting it to true for the MVE case will have knock-on effects elsewhere anyway. > > +static int > > +create_feature_arm_arm_m_profile_with_mve (struct target_desc *result, long regnum) > > +{ > > + struct tdesc_feature *feature; > > + > > + feature = tdesc_create_feature (result, "org.gnu.gdb.arm.m-profile-mve"); > > + tdesc_type_with_fields *type_with_fields; > > + type_with_fields = tdesc_create_flags (feature, "vpr_reg", 4); > > + tdesc_add_bitfield (type_with_fields, "P0", 0, 15); > > + tdesc_add_bitfield (type_with_fields, "MASK01", 16, 19); > > + tdesc_add_bitfield (type_with_fields, "MASK23", 20, 23); > > + tdesc_add_bitfield (type_with_fields, "RES0", 24, 31); Is it usual in GDB to define field masks for RES0/RES1 fields of registers? thanks -- PMM