From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121346 invoked by alias); 21 Jan 2020 02:14:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 121338 invoked by uid 89); 21 Jan 2020 02:14:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=concluded X-HELO: esa2.hgst.iphmx.com Received: from esa2.hgst.iphmx.com (HELO esa2.hgst.iphmx.com) (68.232.143.124) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 02:14:14 +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=1579572856; x=1611108856; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=+jz55qFMO8A/GDChC6dKUqZSZKppDjQ0JpujTq4LFgQ=; b=ExUk4fDwVdzrTmQEwDjLtVJNkdN71+ULjwuVRbmU614o2mdS/+Sbt/r+ KGPJ1eYYhU9bhlvpbHQgZsjFLSYFChCY/ZwfzyPvxA6l63S/Vi+ujepH6 u8/AdYjW0V0x5pYMgkO2nuNguBImuw6qwt0XdAPL6eWVa7GjuhSG1pdnJ nklkhHd0y+266zxcKncg5Vcf8U7VtWuWdNcC0D/HiuPh4FeKks6cU+YRZ 7SYIjmsm9sGEHXjD93FXox+dzbZuMnuraIJz7mRMRmWXRN+Pb0tP/XnYp QntUtfppL78oIjn+QBAaiqNjLWI/IQDHP4PlcliUJezShjmPdQVuJ46Pw A==; IronPort-SDR: 4N2XiGrk4o7UZz2KixjU3dFzpawuMvX7OAPbhCslUVi8ewJmLngCSG/Hubl5PhD/X4VraRKO2F lOEqnNv6v+8jPNO0eZyFxostQt/plFUYk2UMHo2M6XwS+pNSrREdZJWX2pUBKu9imQsFzy4sVm RSWqait1Jh5sbsIHLrDw8AZW8wYIo18V8I2tf617BCldN6zKWQSU1rtdy2/RYwBcBZZdTx4L7D wuRoSImk3Kecq8t0nOnAGUBfm40LX9Re/ID51KJaf8Z4EQKRYg8yis4ox6PDey3dQsKQjigPs7 L8w= Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 21 Jan 2020 10:14:06 +0800 IronPort-SDR: Ua/YQ2IWhZMJ94hHyQiJOPhm11hkzgslLcQL8cjlGfhKfkbO5hRg/aNYuhwfCOP3fAWY24bcMq rs9ShfVD0v80A0tYD7Q60wuYoI1la5ENS5fcZ2Tb9TYi77q6dO+7faJbHzAZOEoEiUnPZIA2et 3D/3eySbGbKAMwXuVDHhZC49EbQ2vll8eGYzg1YUufgg8/ytlq2CfAYzXPD+DjHgfnaNiEc2gi k87wIrsfjve7c1z0xh7xe7o+sqUnIPlNtU21GJIXVIj69Gs1MZeF+bAqjMx9qMinsBz0GcPIGE wh+04wa7YWfVT1cmDzfgnKex 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; 20 Jan 2020 18:07:32 -0800 IronPort-SDR: H/RqhRh7166l15m2rN3w6GplcpjF5fV1Iu1ThUh4A98Vd+2qoNlufQlEXbj9wvUhjnKma3eGcl E5VIxzWm3zIoBKOKnMiDiLPkC6/0WwliNVYYS5h+xTisco4kJWET90UTyU4+MB+8HN7BkxXGmj 6tusWprZeW7gba4HjVTjqPK1pKw63/tUC3nQQs3Kk1+U50S6+Ir9QTfA5dZIt5WmTRU2RFSMuG JqvCTl7XbwT6qjKKUzKza1DkZRfqRoGVVDXGshNw+ALV8Ey68NIa+zyWyK8V+qGj0ek0I6zIS7 PSc= 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; 20 Jan 2020 18:14:04 -0800 Date: Tue, 21 Jan 2020 02:17:00 -0000 From: "Maciej W. Rozycki" To: Simon Marchi cc: Jim Wilson , jiangshuai_li@c-sky.com, Andrew Burgess , guoren@kernel.org, gdb-patches@sourceware.org, =?UTF-8?B?5aSP56uL5pa5?= , yunhai_shang Subject: Re: [PATCH] riscv: add gdbserver support In-Reply-To: <3a15e9f5-099f-3be0-e3f1-0e17c2959158@simark.ca> Message-ID: References: <00e401d5cb52$63a4d000$2aee7000$@c-sky.com> <3a15e9f5-099f-3be0-e3f1-0e17c2959158@simark.ca> 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/msg00620.txt.bz2 On Mon, 20 Jan 2020, Simon Marchi wrote: > > Offhand I can see the proposal fails to implement XML register > > descriptions, which I think every modern port is expected to do (we also > > need to disallow non-XML-enabled RISC-V stubs in GDB proper, as we > > discussed before; I fail to understand why it wasn't done right away with > > the initial implementation, as it's quite straightforward and would have > > set the policy for debug stubs right from the beginning). > > I would also expect new ports to use XML target descriptions. And I see > that there is already code in arch/riscv.c to build target descriptions based > on detected features... so should gdbserver use it? Yes, that's what I used with my implementation; a minor change was required for `riscv_create_target_description' not to return a `const' result (or `init_target_desc' couldn't be called on it). Unfortunately the result is not accepted by GDB proper as it does not know architecture names produced by this code (and native support bypasses this step as it uses a different code path for XML description setup). I haven't got to fixing that yet and therefore I have concluded my `gdbserver' implementation is not ready for upstreaming at this point; test results, although clearly not catastrophic, are also affected by this problem I believe. Maciej