From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66481 invoked by alias); 24 Jan 2020 13:32:22 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 66466 invoked by uid 89); 24 Jan 2020 13:32:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=fix!, his X-HELO: esa5.hgst.iphmx.com Received: from esa5.hgst.iphmx.com (HELO esa5.hgst.iphmx.com) (216.71.153.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Jan 2020 13:32:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1579872741; x=1611408741; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4DzycvBw83O9I9dPibw42iREK+ekMKV8kOcTx4hir9Q=; b=aO7rTrgd1xm5fteU/y7EvWopHJe4y0RXjwuFFkEUkhvnNIp6hEp6rKhG bOTFENApdymDSAuVzj3K2sJebwRH1Iqbdi7l0Mn8N3PCegF0rU7KObDQq jAzk9hgNm+e8HhEMQrAxJHh8enZqWnhYHlBSjeHRg+2g5iCvMbdWAqOzx XO0gc98U3Iv9KJN7yE/LrovXGkjK0q2DofaKjYarjsfCc0mn2B9CUXejg fp3L/A+Jy7CMr0b1zRejYLn834pnJWRjvsFCDXwCHZKP1Z1OJ5oVL9sDm IyPG84U5u8tiHIHhiG44vS2eNGIqtjYldkYgJIcP7H/SKD8VyVO4nA2GK A==; IronPort-SDR: WHA3+F71umEcpi1U6FK9fcjOr3eV1atTso+fYSaTe5VNoRqEPgrEv2V383RNspD3d7wcx93iOs RO2fgDDzTqujUIcQfaCjwCvjsGtuPJ/Jwt1qaebdKMWAJ3dAWewRaNrQoVKkMEY5Y8VA0ahZTv PCTb08kwNxDrpE52ZlJmGeKXlP1PC/8RHc7y8jpHaemrypzaMQP2TzMU64B+h2v6bMVtLOBb0R sNNu2OGlRfJp5VSuAONckkqAieaMAGU9D284vfVs4gdrVLqfufAdVEMNQBxOW/agvJ5vex51oW UZk= Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 24 Jan 2020 21:32:20 +0800 IronPort-SDR: ZA/HlxsszMY+yr19wqKQEBQTTrA4PWm0KCuGGz7OtM2NL0BTzPWydkVxX2FEwDltpXE2x63364 MAPyDV/wZHVh/eLhYxS8BKIutPdXSliYCqnC20/zgoQ2UUIj5YnitHGpuIJp+TVfFQWYRDE55t h+aoYZH+/sD52pq3YrSzS8AKpqur9x8BjCdcPxq985aiOyAYvvo+n+no42bYqGCyeui/ku7gdo ksOkwa7pWa+xgDdBtoQVS3SuzK3xNx27vQWNXAU1cB9OtgQq9LW53IbYNTPNklJKAx8ZSIrqhI XlI9hb3yZPlp2T3hzK6AP4tc Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2020 05:25:40 -0800 IronPort-SDR: K7VZoGE3HMYn9NpOIY+UH3eKfizsnMXeumScsWWPrpnuedaCK5IZ7bqtSIqEae0xPX2LJoPygC X5Sufwxro7dl+AJPn0ARPbHvYV4dYHOXdWiZCs76qeQwgM5ShZQPlpKq2GwXv5mWOMV79yu2fU I1O73tu0j+hJP2rvPr7gVA/pqScTQH4D3wAZpUiODauSL0RbXoLOW+DZwXe4F8wT7cMTtY3CQ/ 27Bmi9Zwosav4WgOF2XzPed8Lf9jzqWWwn9wrTVOjam6ZwoSeWebC6MBF4o43VnXjqY9l3vGG9 OeM= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2020 05:32:18 -0800 Date: Fri, 24 Jan 2020 13:32:00 -0000 From: "Maciej W. Rozycki" To: Jim Wilson cc: binutils@sourceware.org Subject: Re: [PATCH] RISC-V: Fix gdbserver problem with handling arch strings. In-Reply-To: <20200124020844.9915-1-jimw@sifive.com> Message-ID: References: <20200124020844.9915-1-jimw@sifive.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2020-01/txt/msg00352.txt.bz2 On Thu, 23 Jan 2020, Jim Wilson wrote: > Maciej reported a problem found by his RISC-V gdbserver port. > warning: while parsing target description (at line 4): Target description specified unknown architecture "riscv:rv64id" > warning: Could not load XML target description; ignoring > > We only have two arches defined, riscv:rv32 and riscv:rv64. Both bfd and > gdb are creating arch strings that have extension letters added to the base > architecture. The bfd_default_scan function requires an exact match, so > these strings fail to map to a bfd_arch. I think we should ignore the > extension letters in a RISC-V specific scan function. I think it's an acceptable solution short-term; after all it's not going to regress functionality. However ultimately I think we ought to actually interpret these suffix letters and arm the disassembler accordingly. > Tested with riscv{32,64}-{elf,linux} cross build and test with no regressions. I'll push it through GDB testing with `gdbserver' yet, once my current native testing has completed (which BTW will take till the end of today only as it seems to run ~4 times faster now; presumably some test cases do not time out anymore). > Not committed yet in case anyone wanted to comment on it before I check it in. I'd suggest naming the new function `riscv_scan' or suchlike, even though it's static, so as not to pollute the generic namespace. We even have a precedent already with `riscv_compatible' nearby. Thanks for the quick fix! Maciej