From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128129 invoked by alias); 20 Jan 2020 23:33:20 -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 128121 invoked by uid 89); 20 Jan 2020 23:33:20 -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=UD:au, Wilson, Jim, acceptance 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; Mon, 20 Jan 2020 23:33:18 +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=1579563199; x=1611099199; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=nOg1KA9LBbCAIumdFjzXk0xHzEZeMQaRYOuksvPp234=; b=n9FCUxCKo5d54nxYgdgPBj1PX+CJH0W0kvtP7kHf7je/RQjShqm9VSlu A7B/p6ry7SQAs1f0YhcMSbUCYQnW15RT1WxYLYfFjUKTK9RdgWy7rnNl5 mRHXxYZz21MqmAoaLG2gRsZu+zSh+EPr6Kk8+PNqJDWlIObtdUcNkocPd I5haedH+k7sKt9UU38iu5IEIXZ/jcRhSnUYGhGw/nRhxyYECh/dTCwZX3 YWLdHFhyqIypufEW4kG/BFcfveJlEw0mG2KgCzdtj/30sSJp6dZ/exk7h LU1oz7PpRyGUYXmz6LpQiVP2pw1R0qhNUPHhYDgrY/hSQSE5QeFRuLrJ/ A==; IronPort-SDR: Vuqr1pSb4z04nF7J4ZaPgMNuyhEZcdstgBtxfLSk/7f+2g0++dR77b448E4wA12ZMkg4Lmp6Wb Y7v3YZ7bUGRfrxUlc+KQM4jA0SwcT5p6Pr4akImdjpIIFNKCzwMOlDMinZ7RMsfLhXqC/7H1n/ 5rnjPmj1qj9mSFLIsrq5iHRnI8D/VjtPsTt2yRCk33uWKVxUQ8ew+JrbN1cgVQjbzwwqXWs6UY I580Rw60avP782Qjg31gs83Ew3USfJ6JbxyBJpb5Io5rztbvb86F02oj5B++ly9BShhU7esJ82 zP0= 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 07:33:18 +0800 IronPort-SDR: ZlmdqlMp/tPVrvZ6dlyR/LvHvVbdKi3hDat63cDCrRASlNH8sLnYBgFeDnv2jfe5MbpfUvES9e IrLv5X3u+O00/zV+cFsWJTzy9DO8zaKzA1OHR2hhOrV0O4TB997WvTCfsd5ZiHi+vEX1Bt6ia0 Ss3ih+Oksdk0FzUhJkFbTpU48Tu0Md+dVmdXpwvQgSlzZ4+3Mbkd+NDXDfjZEJ5BMZa3icA7P0 oMNpeR/WEuOjWxg5/9IK0qz9ugFxiMZXonho/3N1PraSO2C08EnTDiOGLo+IpjabJ1EvrdeON2 CK/29ZTSm8ReIZqqFXULZrhv Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2020 15:26:44 -0800 IronPort-SDR: foxmFk0MPPtq/3BO/bHHaMxF3UNzKiLTEIoGTaNrrIiI7bPqeqU098zBZ/eUOAHt8w7AWkRYea 232Hl+GLRlHdYgz0HnKBEBPCdV1Qem/y+/1olRVHHbe3+ROWyean6DAb3FYNbtGfFnKLtWYXyk zzlWcb7aMn76OjXzGMWcNvC3S5gUeBGmclK6F1dEwSm1CNsOB2Ew/j+Jbp9/AsG/qibAVHh2UH KYcl6Wy8Nr4wc6VhRMjfe3bjgMIT9FRxsHkTkvPZC6L6T0shvDEnGUhVfcltBkodFHzp2BXkI5 7Kk= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2020 15:33:15 -0800 Date: Tue, 21 Jan 2020 00:30:00 -0000 From: "Maciej W. Rozycki" To: Jim Wilson cc: 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: Message-ID: References: <00e401d5cb52$63a4d000$2aee7000$@c-sky.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/msg00616.txt.bz2 Hi Jim, Thanks for the heads-up! On Mon, 20 Jan 2020, Jim Wilson wrote: > > This patch is a base support for Riscv32 and Riscv64 arch. It implemented > > how to > > r/w gprs and fprs, identify the software bkpt insns and the *.dat files for > > regs_info. > > I have tested it on kernel 5.1.15, and it works normally. So what are the test suite results compared to the native port? > I believe that Maciej has a RISC-V gdbserver port also. It would be > nice to see some comment from him. Indeed, however I have stalled my work as my fixes for GDB issues triggered in the course of this effort have never been reviewed in some 2 months now (I continue pinging, but nobody has bothered to pick them up, even though I think at least some of them are straightforward if not obvious), so I focused on some GCC issues instead. Also a bug needs to be fixed with GDB proper not accepting the XML architecture names generated by itself (i.e. code shared between GDB proper and `gdbserver') or XML descriptions generated by `gdbserver' are rejected. 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). > > Some requirements may be implemented later: > > 1. if fpu has 64bits in riscv32 > > This is common, and will have to be fixed, but not necessarily fixed > in the first version. We also have riscv32 linux targets with no FP > registers. I don't know what the *.dat files are for, but I think the > general registers and the FP registers should be separate files if > possible. If not, then we need 6 dat files, as we have 2 general reg > sizes and 3 FP reg sizes, and 2*3=6. I have a version that supports 64-bit FPU across both RV64 and RV32, as required by the Linux kernel; a fix is required for the native port as well, which I have made too. The .dat files are not needed by our port AFAICT, because it generates the XML description dynamically, and they are only used for the ports that do it statically. I'll look into this proposal more deeply once I have fully recovered from my last week's trip to linux.conf.au; or maybe I'll just post mine instead, as it lacks some of the deficiencies discussed here and I expect it to be fully functional if not the XML acceptance bug on the GDB side. NB my RV64 HiFive Unleashed test results look like below: === gdb Summary === # of expected passes 58054 # of unexpected failures 621 # of unexpected successes 4 # of expected failures 49 # of unknown successes 5 # of known failures 72 # of unresolved testcases 110 # of untested testcases 100 # of unsupported tests 232 however I have not analysed them further, due to the reasons stated above. HTH, Maciej