From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63572 invoked by alias); 26 Jun 2018 19:15:44 -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 63318 invoked by uid 89); 26 Jun 2018 19:15:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Jim, H*F:U*tim, H*c:alternative, states X-HELO: mail-ot0-f178.google.com Received: from mail-ot0-f178.google.com (HELO mail-ot0-f178.google.com) (74.125.82.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 19:15:16 +0000 Received: by mail-ot0-f178.google.com with SMTP id k3-v6so6683379otl.12 for ; Tue, 26 Jun 2018 12:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mRUg7zTvll2Q919fWVN40Mf5953ox2bJbT9Jqw0cHqg=; b=mymVuC0JFS/N7Pep2uTyEgByciFnVlL1fy6zFKkD9dUeq/6UHJd/A2w2spV+RRtW1/ KCFskaAZCE/IkkBB09llNWY5OAIXa/8f6XpyxBmmolywqq4ZUD8AmdXUsS17wy/ppjTz vHtp0iFJGae3NiYb3O+3iyhJ0AbPhsIDaFAkujXIQYfFnxf0dID36ikPZLwhuZPWSqoF m1UOPpPHdPBJl5e5FmH7HvdVJvVYQvvnzD8QMEBBDVMYklq7YDHX58JIB5DUJWjU9Dwn Z9fpaveB1JiTGSTqAPevVecSH7czp3RJrMGW00fFRLe+ZRhgslvk9GnYxKfdsc6b4+Zf RILQ== MIME-Version: 1.0 Received: by 2002:a9d:4d0d:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 12:15:11 -0700 (PDT) In-Reply-To: References: From: Tim Newsome Date: Tue, 26 Jun 2018 19:15:00 -0000 Message-ID: Subject: Re: RISC-V: decr_pc_after_break causing problems To: Jim Wilson Cc: gdb , Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00011.txt.bz2 As another point of reference, the gdb we use with OpenOCD does not have the set_gdbarch_decr_pc_after_break line at all. Tim 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)); > > The privileged architecture spec v1.10 states in section 3.2.1 that > the ebreak instruction causes the receiving privilege mode's epc > register to be set to the address of the ebreak instruction, not the > address of the following instruction. So gdb should not be > decrementing from the pc after a breakpoint is hit. > > It isn't clear why this code is even here, as it isn't present in the > original gdb port in the github riscv/riscv-binutils-gdb tree. > > Curiously, there is a corresponding bug in the riscv linux kernel > sources, where it is adding 4 to the sepc in the breakpoint trap > handling code for no apparent reason. This might be OK if this was a > 4-byte breakpoint instruction, but is not OK if this is a 2-byte > breakpoint instruction. > > In order to get compressed breakpoints working on a SiFive HiFive > Unleashed board running linux, I need both the gdb and the linux > kernel bugs fixed. The 4-byte breakpoint instruction works OK now, > but is not safe to use in code compiled with compressed instructions. > A good example is in the shared library support where _dl_debug_state > is a 2-byte function located 2-bytes before _dl_debug_initialize, so > placing a 4-byte breakpoint at _dl_debug_state overwrites the first > two bytes of the first instruction of _dl_debug_initialize causing it > to segfault. > > I can submit patches for gdb and the linux kernel, but it would be > useful to know why gdb is trying to subtract from the pc after a > break. Maybe someone has a part that doesn't conform to the v1.10 > privilege architecture spec? I noticed that this epc == breakpoint > address is not stated in earlier versions of the spec, which makes > earlier spec versions potentially ambiguous. If we need to support > parts that don't conform to v1.10 priv spec then that makes the fix > more complicated. It isn't clear how gdb is supposed to detect > whether a part conforms or not. Maybe we can add an option to turn > this decrementing on > or off? Maybe a configure option to select whether it is on/off by > default? > > There is another problem here incidentally that there is an option to > turn on/off compressed breakpoints, but it doesn't affect the amount > we subtract from the pc, which means this option can't work as > currently written. This problem goes away if we stop decrementing the > pc in gdb. If we have to keep the code that decrements the pc for > some targets, then maybe we should just eliminate the option. It > isn't safe to use 4-byte breakpoints in code with compressed > instructions anyways. And there is no point in using 2-byte > breakpoints in code with no compressed instructions. > > Jim >