From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) by sourceware.org (Postfix) with ESMTPS id 325443858D39 for ; Mon, 14 Feb 2022 11:24:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 325443858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-vk1-xa2b.google.com with SMTP id t19so7486913vkl.0 for ; Mon, 14 Feb 2022 03:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AWAjB1zcC5gFYlGFeJ3NhJoibHZsx+bwTHOQpVd4+jA=; b=OfPU+WrZs7juO6bwbLeZWYc+5Sum/bWrIt72z+lmdixA0NzsG0NoRoJVhNAV8ubn6F Ediclcvd/iC0SjzOaLiIw9F3r02fkDi88A7PEHnH5EEyIQr1ss4JFhiiPWvznOQGdnir FuUBQS1ImgIX3EYf0T5f6rbOBw8+L6BZBGJlyPJpMF2dAoWEo50kM6F+NIT8umBK49eB pmi2tagfR/lpcS9iYGfZlDbbkJ7MkbZGeKF/Hn0aKxiQQ9AelFsQWKFBc4WfeID4LNYQ 6kQfrdCQqOJ8i1h4l/hUZpMFQ1nM82mvcvjqurrfv+eo0qfGg3uvbWEuTPODd4yb5QAe m84A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AWAjB1zcC5gFYlGFeJ3NhJoibHZsx+bwTHOQpVd4+jA=; b=V4TVAiHkpdG7ydbhqQjd4xu+dJP0tSbDyA/er9DY+rvZHerR/qDasl8d5xLJrKdb5e Vh0Oge7R2zg7IPjxCb0eL0pMyILkz7oxllwI+2r7oyY5BMum5jxazZBMEVYeH35zi+uF 8n8KycGf6KOitupDcME+i5aO4HMNQQMP4GbC6MNLbP2yn1ufM7ZRqY6/L19pRtenfZDb OAbfZHrJ9W1kvDVdTRDvpZoEyc+RRl4EYfy/SwOiibqLcoaHBSiBI7yfzP4vKRFVTaba TMbL0S11sPVpL7ONKKjRLBrKBxVfYLvbLy24RZvdkDVvTUnrA/geHxW0hslAOdhuFHNd ghPg== X-Gm-Message-State: AOAM530Aaqi70LaLJlS7qublQ/AXPuYzDcXAFSwl9rKCXriEyeMSTInd nBG+2SfsN1FvpIgqAmqCW1RzA+GSM4dbzPLPdTLaUA== X-Google-Smtp-Source: ABdhPJzZqFHvSgprKVn0HoRQYurmxF0vfGFz1uQ/22WfLYvowbxtpKC3sCP9qC84D4xUGgb05KjAi7o5ET8nKM9Lgu0= X-Received: by 2002:a1f:ad89:: with SMTP id w131mr3977468vke.17.1644837852684; Mon, 14 Feb 2022 03:24:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nelson Chu Date: Mon, 14 Feb 2022 19:24:02 +0800 Message-ID: Subject: Re: RISC-V: mapping symbols vs "unimpl" To: Andrew Waterman Cc: Jan Beulich , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.3 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, T_SCC_BODY_TEXT_LINE 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 11:24:15 -0000 Hi Jan, On Mon, Feb 14, 2022 at 6:35 PM Andrew Waterman wrote: > > On Mon, Feb 14, 2022 at 12:27 AM Jan Beulich via Binutils > wrote: > > > > Nelson, > > > > with your introduction of mapping symbols I have trouble expressing > > certain spec-conforming deliberately illegal 32-bit instructions (low > > 16 bits all zero). I can't use "unimpl" itself, as that for whichever > > reason resolves to "csrrw x0, cycle, x0" > > I just wanted to remark on this seemingly arbitrary choice: we chose > it because it's both architecturally guaranteed to be 32 bits wide and > architecturally guaranteed to trap. (The CSR in question is > definitionally read-only, and writing a read-only CSR must trap.) I > realize it's of no help to your query, but I figured it was best not > to leave this point dangling. I'm not really sure the history, but according the implementation, https://github.com/riscv-collab/riscv-binutils-gdb/blob/riscv-binutils-2.38/opcodes/riscv-opc.c#L272 The unimp is encoded as "0x000" when rvc is enable, and is encoded as "csrrw x0, cycle, x0" when rvc is disabled. > > (and oddly enough using that > > form as input goes through without even a warning, but that's just a > > side note). I also can't use .insn, as that places requirements on > > the low two bits of the main opcode. And now I also can't use .word > > anymore, as that will cause mapping symbols to be inserted, which > > therefore - by a disassembler honoring the mapping symbols - won't > > disassemble as an instruction anymore. > > > > Do you have any suggestion how to encode a spec-conforming "unimpl", > > which I want to be part of my own disassembler's test cases (in > > particular the 0xffff0000 form)? Since the commit introducing the > > mapping symbols refers to Arm, I'd like to point out that their .insn > > equivalents allow to encode entirely arbitrary instruction forms. But > > of course I understand that RISC-V's insn length encoding scheme is > > somewhat in conflict with this. We are used to checking if the instruction is valid or not for the .insn directive. So this made me think - maybe we should allow .insn to encode any instruction, including illegal formats, just like what Arm/AArch do as you mentioned. > > Two further remarks: Even ".insn ci ..." cannot be used, not even for > > forms with the high 16 bits not all set (which again the main opcode > > restriction would get in the way of): Already just temporarily > > enabling RVC causes the RVC bit to be set in the ELF header flags. > > Yet with that bit set 0xffff0000 is actually a 16-bit insn 0x0000 > > followed by a wider insn with the low 16 bits all set. IOW this > > conflicts with the spec's wording of "minimal length insn with the > > low 16 bits all zero". For now you probably can write 0xffff0000 by two .insn directives. For example, .insn 0x0 + .insn 0xffff, and then you should get something like, Disassembly of section .text: 0000000000000000 <.text>: 0: 0000 unimp 2: ffff .2byte 0xffff Anyway, this is just a workaround. I will find relevant people to discuss whether the .insn directive should be allowed to encode an illegal format. > > And then I'm puzzled by the main opcode restriction related error > > being raised a whopping 6 times for ".insn i 0, 0, x0, x30, ~0", > > and still twice instead of just once for ".insn ci 3, 7, x31, ~0". > > > > Jan > > Thanks Nelson