From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51178 invoked by alias); 30 Jan 2020 00:13:50 -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 51167 invoked by uid 89); 30 Jan 2020 00:13:50 -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=HX-Languages-Length:1437 X-HELO: esa1.hgst.iphmx.com Received: from esa1.hgst.iphmx.com (HELO esa1.hgst.iphmx.com) (68.232.141.245) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Jan 2020 00:13:49 +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=1580343228; x=1611879228; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4l63R5EmpJ66oE/BeJFUN4aoOcJpzPNkcFSMBzMet3M=; b=LuAY3O7AqibRH4xU9spXhw7xoIKbT/5AJDAe9KFBjbqI8jATrQNk/ptX PngCy+n5cbjUHS6V+SPOew8jpYQDHCBHdz5e0jOdy7rVAtb4+JfAwCREL XBDft2vY5BKjNdJ2lXy0uHB+pApQPKNIGAn5zvWfwUzdkOwfmTl3S2dFj 8ZQKTXpKySFRrua7LGO5XWYsxkgy897I5dCRcrdDcEvUAhESvIuoRcIf6 SoMEmggqanHmhcoWgxm5JbMT0IvLd5vdAERVCKmBWTYTP7v43nSgmzfpE 2Ieka0Rzh+UjbmAdzlMUF3UgizxD4+2kTnERWdhbyLmQGd4cxq4V5KQEU g==; IronPort-SDR: 3TYVXjJvEeHO1pQAkQsAjpGeVnhcMCObTOKbzwO0ih/jktiRRM7XwBHjv+kgAeqpkLewEZ5JkW KXAAH5D5UqPwKuyJJMXOnOHGVjRzUK8CkBuB3tXxXj1IGije5YqaUPKFMk+N6KQRqYmWeL81mH UJashBzY4TiyqHnJTUt1T6zvR0LOoUenGkhGZQCAiZ0lpt14RYx+6wce4PxhD9onoZUzSKKHhI 0CbwqTSNYlQjkP6Yj7KI1/qrEXvvxSzjSSApKRn+qG1alL6JAL75EMoAlClsYMS6/5D30j9VxX 0bI= 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; 30 Jan 2020 08:13:46 +0800 IronPort-SDR: PGsX7hxa47Bx+Xw0ivUF85NomPLhNPNJQigbXxDkKDDRLAfItKQV0VO+oUCJE2W/X/HYbMQzlP NHi0EKoAFKVTidPLx3ePZBF7LZrKBHMmirtKEgTK1hXy0uA7d5KtgOsEfQ1kahWMjs0BXgiApP vhfeE2xudiYs6QNJjtqaMRn9IkSzKpXKVdn9333VM91uYRdD8X4+nXl8qmAzMvmiBQxr6r7T8/ jVSBNz7186OugsUHNK69FvGSeFkP/k71xU2i2nX3UvKJQIAMlXu1fRqGJIaSQo0L/v+wUMQz0t UQDfbEuQzDvSw/Y3oSkQ/hL0 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; 29 Jan 2020 16:06:58 -0800 IronPort-SDR: TkzrLTdfNy0VxljMrp4TlQLNq9ubgAeeF2qGispTPkU3hI+EAveZMvix/NHee0829a7asUyJZu KKUeuvIcrnzM/LpJGSaopO6jbbkMtbQBXYN7qv/EGrZNoN+96Soh0CJ6aZda9ponaVUNT0RTvj PYJopv+U01uJphfesNJgKoatYeXGFq7Nj6IDRTYOrZC9jNJSKLfTAXKeavYPgUwASRIFOvSNwv MW+yKPiMjV5onvu8U46p3uzO29dKEUEj2zDPgzjhe6vLMOxJAsmWrDUQmX79WoVgDBZIrU5r5G Emw= 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; 29 Jan 2020 16:13:44 -0800 Date: Thu, 30 Jan 2020 01:58:00 -0000 From: "Maciej W. Rozycki" To: Jim Wilson cc: "gdb-patches@sourceware.org" , Andrew Burgess , Palmer Dabbelt , Tom Tromey , "guoren@kernel.org" , "lifang_xia@c-sky.com" , "yunhai_shang@c-sky.com" , "jiangshuai_li@c-sky.com" Subject: Re: [PATCH v2 3/3] gdbserver: Add RISC-V/Linux support In-Reply-To: Message-ID: References: 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/msg00965.txt.bz2 On Wed, 29 Jan 2020, Jim Wilson wrote: > I noticed on the gdbserver console I'm getting a lot of ptrace warnings. > ptrace(regsets_fetch_inferior_registers) PID=1678103: Invalid argument > Warning: ptrace(regsets_store_inferior_registers): Invalid argument > This looks like a side effect of having two FP regsets defined, it > tries the first one, fails, and then tries the second one which is > correct. If you mark them as OPTIONAL_REGS we would only get the > warning once which would be OK, except that they can't be both FP_REGS > and OPTIONAL_REGS at the same time. I don't know what if anything > would break if they aren't marked as FP_REGS. I only see explicit > checks for GENERAL_REGS and OPTIONAL_REGS; I don't see any checks for > FP_REGS. Anyways, I would suggest as a future improvement that the > linux gdbserver regset support be extended so that a regset can be > marked as both FP_REGS and OPTIONAL_REGS. Hmm, good point. I think OPTIONAL_REGS might become a flag, however as you have observed there seems to be no special meaning indeed to FP_REGS and actually only a couple of `gdbserver' hosts use this type, so using OPTIONAL_REGS should be fine. I'll send an update. > There are some new functions and structures that don't have > explanatory comments before them, but this is a minor issue. Right, though I think they are self-explanatory. Maciej