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 422453858D33 for ; Wed, 22 Feb 2023 22:56:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 422453858D33 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: by gnu.wildebeest.org (Postfix, from userid 1000) id 8215830067AE; Wed, 22 Feb 2023 23:56:48 +0100 (CET) Date: Wed, 22 Feb 2023 23:56:48 +0100 From: Mark Wielaard To: Martin =?utf-8?B?TGnFoWth?= Cc: Andreas Schwab , elfutils-devel@sourceware.org Subject: Re: [PATCH RFC] backends: Add RISC-V object attribute printing Message-ID: <20230222225648.GC1713@gnu.wildebeest.org> References: <772d9a17-3a8b-df94-24dd-51756ecfb3f9@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <772d9a17-3a8b-df94-24dd-51756ecfb3f9@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3031.2 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, On Fri, Nov 25, 2022 at 05:29:19PM +0100, Martin Liška wrote: > On 10/13/22 16:53, Mark Wielaard wrote: > > 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 = (q - name == sizeof "gnu" > > && !memcmp (name, "gnu", sizeof "gnu")); > > gnu_vendor |= ebl->has_gnu_attributes; > > > > Or something similar? > > Andreas: Can you please take a look at this? Has anybody had time to look at this? Thanks, Mark