From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104834 invoked by alias); 15 Oct 2019 19:53:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 104825 invoked by uid 89); 15 Oct 2019 19:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CABvJ_x, H*f:sk:CABvJ_x, U*vincent.chen, yourself X-HELO: mail-vk1-f196.google.com Received: from mail-vk1-f196.google.com (HELO mail-vk1-f196.google.com) (209.85.221.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Oct 2019 19:53:32 +0000 Received: by mail-vk1-f196.google.com with SMTP id d126so4638183vkb.1 for ; Tue, 15 Oct 2019 12:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qUBZdIBfSqlctW1AUcxBoh3cJ82uC6u2poIbQZtNiPM=; b=TR2XPDK+Lb6Spa7itQJHpDEaInD7TIXDCu2pisWA0CSQ76aNnRvFjnrxO7Ha5x5grY J2LdmxcIBtT+ix9gZ7eaIeY+jJm12IxSuMdvdAcj6ICEFRTdCaDqOsTl+xhY+ETcD2+o wDgeiMnJov/ebrbEyw2QVxpQ0rDmrTo/MXOoYBWTorS+KjI/+wwEk+xwZn9yBy4SLqjU gVVh8j2HZGcHwNguqRF39FXvBVzFbUynAX0w6AO4T8+wiZbmizIzLE2JB/YZX6tOM9RH VeU8HDcJhFOl1OkHs6k/FDmKSZCPg3L0KxISOh9uft+GNcDd5llAd70GKBO90mtpaL5U SEdQ== MIME-Version: 1.0 References: In-Reply-To: From: Jim Wilson Date: Tue, 15 Oct 2019 19:53:00 -0000 Message-ID: Subject: Re: RISC-V: Is it reasonable to extend current target_description for KGDB? To: Vincent Chen Cc: gdb@sourceware.org, Paul Walmsley Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00011.txt.bz2 On Tue, Oct 15, 2019 at 12:43 AM Vincent Chen wrote: > namely 32 GPRs, $PC, $sstatus, $sbadaddr and $scause. Therefore, from > the viewpoint of KGDB, if the register list of the 'p' packet can > include these 36 registers, the complex implementation for the > register query flow will be unnecessary. We don't have a dedicated RISC-V gdb developer. If you need gdb patches, you may need to write them yourself. Excluding riscv linux native, the other important targets (openocd and qemu) use xml, and would not be affected by changes to the default register list. I don't know how this would affect riscv linux native. Someone would have to try it and see. But since we use ptrace instead of remote, I don't think that it would be affected. We probably have other unknown targets that might be affected but no way to identify them. There are a lot of people using RISC-V, but not very many contributing back to the FSF sources, or even the RISC-V Foundation sources. I think Maciej may be working on the missing RISC-V gdbserver port, so his work might be affected, but I would expect gdbserver to use xml also and hence it should be OK. One possible solution is to add a RISC-V specific command to choose the register set used for the default p packet. That way, if there are problems with adding registers to it, people have the option to switch back to the old way. We already have the "set riscv use-compressed-breakpoints [auto|on|off]" command. So we could add a similar command to choose the number of registers in the default p packet, try changing the default to the full 36 register set, and wait to see who complains. People that complain can be told about the command to switch back to the old 32 (33?) register set. Jim