From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 506943853D5E for ; Wed, 23 Nov 2022 08:40:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 506943853D5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id ABE0D300089; Wed, 23 Nov 2022 08:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1669192856; bh=c8EH51IFcQE7e/xXbwWOTmZJ9ekDkUU2rC8oO/vecac=; h=Message-ID:Date:Mime-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KmE79l+nsQByLgGhM2GL9+5dZeR4AQyXxAvlsyggOeTEuNykd+XE4DbUPE2JNhQEK AnYaGzIzxK7cGetKVJ6tb4kl2Mq/rsPldPSKMuatWdXjAut/zpEwRgsVMHkBoDPo8Y lX+e2hvPsPLqLvLeOE8+jIqrhkwQUK1Xw43wcXwM= Message-ID: <133194e3-cde8-ac92-6e31-c3be609e352b@irq.a4lg.com> Date: Wed, 23 Nov 2022 17:40:54 +0900 Mime-Version: 1.0 Subject: Re: [PATCH 2/2] RISC-V: Better support for long instructions Content-Language: en-US To: Jan Beulich Cc: binutils@sourceware.org, Nelson Chu References: <8eeba059-8d4f-b147-27e2-49e505c490a9@suse.com> From: Tsukasa OI In-Reply-To: <8eeba059-8d4f-b147-27e2-49e505c490a9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP 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: c.f. PATCH v2 2/2 On 2022/11/21 16:37, Jan Beulich wrote: > On 19.11.2022 08:10, Tsukasa OI wrote: >> From: Tsukasa OI >> >> Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit >> instructions with .insn") tried to start supporting long instructions but >> it was insufficient. >> >> 1. It heavily depended on the bignum internals (radix of 2^16), >> 2. It generates "value conflicts with instruction length" even if a big >> number instruction encoding does not exceed its expected length, >> 3. Because long opcode was handled separately (from struct riscv_cl_insn), >> some information like DWARF line number correspondence was missing and >> 4. On the disassembler, disassembler dump was limited up to 64-bit. >> For long (unknown) instructions, instruction bits are incorrectly >> zeroed out. > > Just FTR - of these 1 and 4 were deliberate (as in: deemed acceptable), the > former the keep the code reasonably simple and the latter because focus was > solely on the assembler. I thought it's possible that 1 was a deliberate choice. I don't want to depend on some internal structure that could change easily (as long as this is a reasonable choice). To be honest, I didn't like my "extracting prefix of an instruction" logic in PATCH v1 but I found a good function: generic_bignum_to_int32 and decided use it on PATCH v2 (as a result, PATCH v2 2/2 is a bit simpler than PATCH v1). For 4, resolving from the start would be better but since my current focus is the RISC-V disassembler, I'm happy to resolve it (fortunately, it didn't require large changes). Nelson assigned you as the person who makes the final judgement for this series and I want to hear your thoughts/decision about PATCH v2 2/2. Thanks, Tsukasa > > I recall dealing with some instances of 2, but as you demonstrate I failed > to recognize and deal with further cases. > > I will admit that I didn't even think of debug info generation. > >> To solve these problems, this commit: >> >> 1. Handles bignum (and its encodings) precisely, >> 2. Incorporates long opcode handling into regular struct >> riscv_cl_insn-handling functions. >> 3. Adds packet argument to support dumping instructions >> longer than 64-bits. > > Thanks for taking the time to make improvements there. > > Jan >