From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id B837A3858403 for ; Mon, 12 Sep 2022 19:42:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B837A3858403 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x630.google.com with SMTP id wc11so8083646ejb.4 for ; Mon, 12 Sep 2022 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=LTS9YWQH6QqFS8/RqAoSi77LQYUt3vusUgBbZ32N1Ck=; b=NKb1iMwrM7KZD7cgaQPcHTn/tvM3sX1HI9YtRluDiKafQ/lYEx9ARgF8ENDTD1IW+I 0MRtfNqKgoeGeGUTTEpgARvRjRYraxvQSwH4zK1oqumBjdi2Q7eDhC9UE6WxHIx/4f86 i6jMuYeETbCRj21qkKie8cJ9Ug4snJbOevpQZeK9GWHWmOlry2BP+zK8L0tsE9mQhLls ze4MxlRV1ltdn8N0p7E5jKEk7XxJp4Bsl/eXVGhzEMUGz+uet3Lxke81BbrMErR1oKwQ d5u/aVH5HMjLWY4ylMX7Uaf/GY/rnhnlsTMdNkwmmQJRyO/+VJRfVOFZW4GGxAOpX/Sr 0K+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=LTS9YWQH6QqFS8/RqAoSi77LQYUt3vusUgBbZ32N1Ck=; b=Iyn6KOC6JkJvu+TaHaAIQfQmXH7bwRVLK+wmCnSK1QO8IglTXK6op2FyDgTFOaet1l xuTKodRWEs/DdlEirpuMYiiN693nWZ3PsWgjISjHLVeSpHeJKlxJQr4xHyMP/8W9oxrm leK97kwJiiDh9NYOW+zMvzLRYjyiwlPP/Esy6/MjFZ0a4S20wqb85ojjKCrNmfNzuvYB UgDHqFtoiNhwp5OalROwEc6Ra20TOGWOnH9kfrK69jpn/TFQYMFlb/8tuswvqqqUh5uQ mKGIwpdMFcLTm223oLXF7nzxsML9D5JvFMaAi/D4f6cOhiwwm9cHnaj3rap9AtXhO/7D mGNw== X-Gm-Message-State: ACgBeo3Y1luol0z0Ubf0g6zgx4AlY1XqoOItqlSpglLlKvUX7buL243d n8rZ7hs1SInllyYpKaFBUq5OyOHCLlrft3KdcKE= X-Google-Smtp-Source: AA6agR5s3ip5sYQNeXzSPMiwm3/NhMQxa94A4ee+1VUUQ0ou7QABGGT9XLpemvtk9oO2TOqIfRYj+er20K1Gn8GaiR0= X-Received: by 2002:a17:906:7310:b0:741:85de:ead0 with SMTP id di16-20020a170906731000b0074185deead0mr20174251ejc.441.1663011720303; Mon, 12 Sep 2022 12:42:00 -0700 (PDT) MIME-Version: 1.0 References: <0355e8b2-1ab7-38c8-f3ba-335a25b685bc@suse.com> In-Reply-To: <0355e8b2-1ab7-38c8-f3ba-335a25b685bc@suse.com> From: Kito Cheng Date: Mon, 12 Sep 2022 21:41:46 +0200 Message-ID: Subject: Re: RISC-V: attributes and assembly / disassembly To: Jan Beulich Cc: Palmer Dabbelt , Andrew Waterman , Jim Wilson , Binutils , Nelson Chu Content-Type: multipart/alternative; boundary="000000000000d89a9f05e880166c" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000d89a9f05e880166c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A quick answer is that should be addressed by mapping symbol, but I am not sure the current implementation status in binutils side, Nelson might be able to answer this. https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/196 Jan Beulich via Binutils =E6=96=BC 2022=E5=B9=B49= =E6=9C=8812=E6=97=A5 =E9=80=B1=E4=B8=80 18:14 =E5=AF=AB=E9=81=93=EF=BC=9A > Hello, > > for use in other work I've been playing with this piece of assembly code > > .option push > .option arch, +c > aliasC: > sll x1, x1, 3 > c.slli x1, 3 > sra x8, x8, 3 > c.srai x8, 3 > srl x8, x8, 3 > c.srli x8, 3 > .option pop > > ending up quite surprised that the resulting object doesn't disassemble > (at least not without giving the disassembler extra options). It then > occurred to me to drop the push/pop of the options, and voila - things > worked. Aiui riscv_write_out_attrs() populates Tag_RISCV_arch with the > state of things at the end of assembly. Which raises (at least) two > questions: > > 1) Shouldn't the assembler accumulate all extensions which were ever > enabled in the course of processing the source, and use that set to > populate Tag_RISCV_arch? Even if that's too simplistic, I don't think > the state of things at the end of assembly can be taken as > representative for the entire object. > > 2) The assembler properly sets the RVC bit in the ELF flags in the > case described. Shouldn't the disassembler use that information > alongside the attributes section? > > Thanks for any insight, > Jan > --000000000000d89a9f05e880166c--