From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 176BF3858C56 for ; Thu, 13 Oct 2022 14:53:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 176BF3858C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id EC4373039EAA; Thu, 13 Oct 2022 16:53:30 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 684E0413CD0E; Thu, 13 Oct 2022 16:53:30 +0200 (CEST) Message-ID: Subject: Re: [PATCH RFC] backends: Add RISC-V object attribute printing From: Mark Wielaard To: Andreas Schwab , elfutils-devel@sourceware.org Date: Thu, 13 Oct 2022 16:53:30 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3033.5 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Andreas, On Wed, 2022-08-10 at 11:27 +0200, Andreas Schwab via Elfutils-devel wrote: > This does not work yet. The RISC-V attribute tags use the same > convention as the GNU attributes: odd numbered tags take a string > value, > even numbered ones an integer value, but print_attributes assumes the > ARM numbering scheme by default for non-GNU attributes. Yeah, I see this comment in print_attributes: /* GNU style tags have either a uleb128 value, when lowest bit is not set, or a string when the lowest bit is set. "compatibility" (32) is special. It has both a string and a uleb128 value. For non-gnu we assume 6 till 31 only take ints. XXX see arm backend, do we need a separate hook? */ Maybe we need a flag in the backend to tell whether attributes follow the "gnu_vendor" convention? So that could be checked at: bool gnu_vendor =3D (q - name =3D=3D sizeof "gnu" && !memcmp (name, "gnu", sizeof "gnu")); gnu_vendor |=3D ebl->has_gnu_attributes; Or something similar? Cheers, Mark