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 7B2533857BA8; Tue, 4 Oct 2022 09:26:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B2533857BA8 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 D4E36300089; Tue, 4 Oct 2022 09:26:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1664875566; bh=iA6vYInF2lhGzbnr1XLQwvQx6L8pfyUw/hmGGBRu3uY=; h=Message-ID:Date:Mime-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HvZbCv1aU1dVKTI4gSmud8+FqWSh5Nd2wpYrpDV2zkmxZTVaIGK7GGK29W3Wgyr4O dlWQ1vxWrvRQSiaI6gtVKYLc0gcH3riB7Gd1lcOizm8ELAW9z2yhYjyNDFmBbrAsdl 3abP/GW1fz+Vwttgio1F6j+o51TAd98xP2STssd4= Message-ID: <8cc87571-4ef6-8474-0c40-186c5e38438d@irq.a4lg.com> Date: Tue, 4 Oct 2022 18:26:05 +0900 Mime-Version: 1.0 Subject: Re: [PATCH 0/2] RISC-V: Fix buffer overflow after long instruction support Content-Language: en-US To: Jan Beulich , Andreas Schwab Cc: binutils@sourceware.org, gdb-patches@sourceware.org References: <227e9854-f0bf-566a-42ef-5f14a145c6dc@suse.com> From: Tsukasa OI In-Reply-To: <227e9854-f0bf-566a-42ef-5f14a145c6dc@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: Jan, On 2022/10/04 18:07, Jan Beulich wrote: > On 04.10.2022 10:59, Tsukasa OI wrote: >> After commit bb996692bd9 "RISC-V/gas: allow generating up to 176-bit >> instructions with .insn", I started to see some crashes while running >> "make check-gas". > > Hmm, I'm puzzled why things worked correctly for me. The extra size needed > is quite significant, so chances should be rather slim for things to work > correctly. I don't see this extra stack size as a problem so far. > >> The cause was simple. Some functions depended on the fact that maximum >> length returned by riscv_insn_length is 8. But since the commit above >> increased that upper limit from 64-bits (8 bytes) to 176-bits (22 bytes), >> we need to increase two buffer sizes to avoid crashes. >> >> But note that this change doesn't really support over 64-bit instructions. >> It can be said on riscv_insn::fetch_instruction because it now may return >> only a part of instruction. >> Instead of merging this, reverting that commit (for now) might be an option. > > Please let's try to avoid reverting - the ability to emit wide instructions > via .insn helps testsuites beyond binutils' / gas'es. I normally agree with you but the real problem is, most of the RISC-V code is not yet ready for >64b instructions. At least it breaks GDB (even with my PATCH v1). I increased the buffer size in riscv_insn::fetch_instruction but riscv_insn::decode (the caller of fetch_instruction) causes an assertion failure. > else > { > /* This must be a 6 or 8 byte instruction, we don't currently decode > any of these, so just ignore it. */ > gdb_assert (m_length == 6 || m_length == 8); > m_opcode = OTHER; > } So, I'll at least submit PATCH v2 based on your and Andreas' feedback to patch minimally required portions but I will keep reverting as an option. With next PATCH v2, at least Binutils and GDB will be "functional" again (so that reverting will be not that urgent). Thanks, Tsukasa > > In any event - thanks for the quick fixing of the issue. I wonder though > whether a connection (at least by way of comments) should be established so > that the same oversight won't happen again (e.g. once the spec spells out > how even wider insns would be encoded). > > Jan >