From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) by sourceware.org (Postfix) with ESMTPS id EF3AA3857007 for ; Tue, 13 Sep 2022 02:08:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF3AA3857007 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-1274ec87ad5so28481613fac.0 for ; Mon, 12 Sep 2022 19:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=ctvL/M58XpY9vUfPlffBxYzWYCrARkUzkbkQcUmIcE4=; b=I+R8y46ieg0flVMmzqUtQVO3f9Qnrj8AxHATkZQCDdwtuUA4NLw1lCFfteuwJvxru6 1KSOtbS9WUUmMpp/HHQcSYbVVfKBl2H2z2iKTsruPKG6NUoZOONzGKLSsTH2IEgbB3R3 FBOiNhQPtSZvb3+3PgobIYBhANet8kxuCN+8OrBiyOrhMX+xylBljFpAslbuzoaLguKu JhBnfmCNbDkWxaRQtf3H7lsZDgFT70/gCruBVh2yqhLlFe98+FOAvmSsGy71lDbq9NVu GaAlg0KL0BTE/VTbiPSLfQsH7cQexzfJZvgyxxGySIsw7BJ1DhoHpxv9s+BZ9b4Ok2cB zNMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=ctvL/M58XpY9vUfPlffBxYzWYCrARkUzkbkQcUmIcE4=; b=1Ii70rEta8tIyJjmDjm9R5LR8B97vYzLD4gx34d7n5sEha/Np8d3o58908wYbPrRG9 U4lO8KIB/wmxMsjGArpxuWqnDvD9aL4P0scF4XX4U9kDeViEjg7FBtlPRYFBNzcTXmVt Pc8mVvbH9LzPKW9zpeYZp6UBGWrtiDMHc9ufwJqM2bGnzSz7l60fXAOnp/L1SnYFy0Sm RNnof8Nfjtdz6x/v/yXhwAHPqiBv/tWXIpLEuCjKGyTGsN1+avYgpR+OzQOEyfjqybTa XAsVXQiVUgSBdH7zvZDl4qDgXSHpgRFoHpoYBJo5u05qSQwpciLTTOaI1TuzxKkzvzf6 eveA== X-Gm-Message-State: ACgBeo1AfCkc9kZP39bP78jMbTrQEwTWgn7WTnegODzrGBucDvSBa/NZ NGZoUBq3q1nMZWSl6S3bkcU9z3kcjvhaYO0p3z3S5A== X-Google-Smtp-Source: AA6agR482l9UJYLRcUJohrG8Xg0AXgxbLs+qP0aM3IA6x2llVgFnB9BHwMEeq6s8UvB9ynRx5QtzMkzfc4qFTdxMmYc= X-Received: by 2002:a05:6870:831f:b0:11c:dfe3:ef6d with SMTP id p31-20020a056870831f00b0011cdfe3ef6dmr647475oae.107.1663034893820; Mon, 12 Sep 2022 19:08:13 -0700 (PDT) MIME-Version: 1.0 References: <0355e8b2-1ab7-38c8-f3ba-335a25b685bc@suse.com> In-Reply-To: From: Nelson Chu Date: Tue, 13 Sep 2022 10:08:02 +0800 Message-ID: Subject: Re: RISC-V: attributes and assembly / disassembly To: Kito Cheng Cc: Jan Beulich , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,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: There was a prototype, https://sourceware.org/pipermail/binutils/2022-August/122220.html. The updated_riscv_subsets boolean avoids generating repeated mapping symbols with ISA ($xrv...), if the ISA is the same as file-level elf architecture attribute or the previous one. But in practice there is a bug in that prototype - we still need to generate $x or $xrv... when it is at the start address of sections, even if it has the same ISA. Let me see if I can find a better solution for the problem, maybe each segment should have its own updated_riscv_subsets boolean or ISA string. Thanks Nelson On Tue, Sep 13, 2022 at 3:42 AM Kito Cheng wrote: > > A quick answer is that should be addressed by mapping symbol, but I am no= t 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