From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60840 invoked by alias); 11 Jul 2018 14:52:56 -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 60831 invoked by uid 89); 11 Jul 2018 14:52:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pull, riscvtdepc, riscv-tdep.c, UD:riscv-tdep.c X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Jul 2018 14:52:54 +0000 Received: by mail-wm0-f68.google.com with SMTP id z6-v6so16345365wma.0 for ; Wed, 11 Jul 2018 07:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ml0E/pIhO5OGygtZSDKOfOajnYn5Whz2rWlm6OyfQU8=; b=ZjigdfMRu3yLv3HWHKtubJYNYKiuKBTSGfM9xZXA1olTrlvvqaGj3lUvelkj3asmUY pcKY3OJHV+dMj/xVQRc81uVYyuGk+WjbtC9Ll1P2jEytj2F9bDio/cXCxplI0xzAmjNg i9KfSo9vaHQnpMVujPyu1jwoNevj1+KNHzSVL8P0I1w1nyLI3s5bWsNUEd1udlGFXNZy xm+yO5n108hVX5ZlAM9PXdgVQz8r2+lf1Yk4pdjc0CZMlWHIHGrKJxr52IfibY5BVbZb LdUx0tDIsRH9JpFnI3kicx6XUL1EX0idco8/0cSp3cACemvkOfCAtyHa30vpBPRJwEKF S4HA== Return-Path: Received: from localhost (host86-164-199-62.range86-164.btcentralplus.com. [86.164.199.62]) by smtp.gmail.com with ESMTPSA id l15-v6sm1585514wrt.67.2018.07.11.07.52.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jul 2018 07:52:50 -0700 (PDT) Date: Wed, 11 Jul 2018 14:52:00 -0000 From: Andrew Burgess To: John Baldwin Cc: Palmer Dabbelt , Jim Wilson , gdb@sourceware.org Subject: Re: RISC-V: decr_pc_after_break causing problems Message-ID: <20180711145249.GG3978@embecosm.com> References: <95eb8848-182b-dab4-f9dc-298269885f53@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95eb8848-182b-dab4-f9dc-298269885f53@FreeBSD.org> X-Fortune: Adapt. Enjoy. Survive. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00027.txt.bz2 * John Baldwin [2018-07-05 15:54:32 -0700]: > On 7/3/18 5:35 PM, Palmer Dabbelt wrote: > > On Tue, 03 Jul 2018 17:17:04 PDT (-0700), Jim Wilson wrote: > >> On Mon, Jun 25, 2018 at 7:54 PM, Jim Wilson wrote: > >>> The RISC-V port in the riscv-tdep.c file has > >>> set_gdbarch_decr_pc_after_break (gdbarch, (has_compressed_isa ? 2 : 4)); > >> > >> I'm still hoping to get a response to this. I need to make > >> coordinated fixes to both gdb and the linux kernel to get breakpoints > >> working correctly. > > > > Andrew: I think this materialized itself when you submitted the GDB patches, > > probably because we have this in our Linux code: > > > > asmlinkage void do_trap_break(struct pt_regs *regs) > > { > > #ifdef CONFIG_GENERIC_BUG > > if (!user_mode(regs)) { > > enum bug_trap_type type; > > > > type = report_bug(regs->sepc, regs); > > switch (type) { > > case BUG_TRAP_TYPE_NONE: > > break; > > case BUG_TRAP_TYPE_WARN: > > regs->sepc += sizeof(bug_insn_t); > > return; > > case BUG_TRAP_TYPE_BUG: > > die(regs, "Kernel BUG"); > > } > > } > > #endif /* CONFIG_GENERIC_BUG */ > > > > force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)(regs->sepc), current); > > regs->sepc += 0x4; > > } > > > > There's at least one bug in the Linux port here: we can enter a breakpoint trap > > via either ebreak (a 4-byte instruction) or c.ebreak (a 2-byte instruction). > > c.ebreak is necessary for a sane debugger so we need to support it. Our > > options are: > > > > * Handle c.ebreak in Linux and leave this as it stands. > > * Remove both the Linux PC adjustment and the GDB PC adjustment. > > > > I'm inclined to take the second option as it's less code. I suppose > > technically it's an ABI break, but since it's broken anyway then I'm happy with > > taking it. > > > > Is there something I'm missing? If not Jim will submit a Linux patch and then > > we'll pull the trigger on this one. > > FWIW, my preference would be for the decr_after_pc_break match the hardware > which from my understanding of the thread means it should always be > zero. I agree this solution is the correct approach and GDB should be changed. Thanks, Andrew