From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62484 invoked by alias); 11 Jul 2018 17:47:05 -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 62475 invoked by uid 89); 11 Jul 2018 17:47:04 -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=privilege, HX-Received:sk:x12-v6m, conform, overwrites X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Jul 2018 17:47:03 +0000 Received: by mail-wm0-f50.google.com with SMTP id v25-v6so3216304wmc.0 for ; Wed, 11 Jul 2018 10:47:02 -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=3i+meRYheewJJ7KbkwCR5pF4tf7o6FaCW7XFxwqqRpE=; b=V6baHm7TwoyZc12IYhkTKZQZOIcIUfkYydmSNwmBa/Ebouw2NQ4GCNtKP9u9ayyr0M 1adshrNUZh1iHXIrfBo474he4h9zno3M0sr2tDiALqR2IX4hryBoKRfZIQDf1jUmkjQ5 4qGDccUKmBAyfftNW7vR6diheKm5MMIZx5cQ8ZsSy9QmzTxAsqPQ2cOvDhu0kzBwDnDI TeNEltaXqSBDH/3uI9xMo/0gotvXHoD9OXRrsMLssixW10QRvsQgGWP8Vqpg7ZdbWGqS zXZa1bnHN2Ajd0BtCDmKQOOJ2dUCOqrSpv6XrNGnPmEgHrlJK/ro1T7x5K5Vj28/VD9y pQ1A== Return-Path: Received: from localhost (host86-164-199-62.range86-164.btcentralplus.com. [86.164.199.62]) by smtp.gmail.com with ESMTPSA id z5-v6sm19699472wrv.2.2018.07.11.10.46.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jul 2018 10:47:00 -0700 (PDT) Date: Wed, 11 Jul 2018 17:47:00 -0000 From: Andrew Burgess To: Jim Wilson Cc: gdb@sourceware.org Subject: Re: RISC-V: decr_pc_after_break causing problems Message-ID: <20180711174659.GA6398@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: We are all dying -- and we're gonna be dead for a long time. 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/msg00028.txt.bz2 * Jim Wilson [2018-06-25 19:54:14 -0700]: > 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. Maybe I'm going to look completely silly here, but.... ....aren't epc and pc different registers? The epc is really many register, right? one for each privilege level, uepc, sepc, and mepc. The spec is clear that when an ebreak or c.ebreak is hit the contents of *epc are the contents of the breaking instruction, but nothing is said about the contents of pc. > 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. Assuming that my above observations are correct, then when we hit a breakpoint *epc is defined, but pc is not, an implementation could do anything, right? The two obvious choices are not increment pc, or increment pc. Right now my understanding is that GDB doesn't have special support for fetching the program counter from different places depending on the current inferior state (stopped at breakpoint, not stopped at breakpoint). So, somehow the value in *epc needs to be passed back into the pc register (I guess). I'm not exactly sure at which point in the process this is supposed to happen.... I'll have another look around and see if any other target does something similar. Thanks, Andrew