From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38009 invoked by alias); 26 Jun 2018 02:54:30 -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 37919 invoked by uid 89); 26 Jun 2018 02:54:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=privilege, incidentally, unleashed, HTo:U*gdb X-HELO: mail-wr0-f171.google.com Received: from mail-wr0-f171.google.com (HELO mail-wr0-f171.google.com) (209.85.128.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 02:54:17 +0000 Received: by mail-wr0-f171.google.com with SMTP id c13-v6so5616189wrq.2 for ; Mon, 25 Jun 2018 19:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=mvdr8ekDQ0NZ4STrXNYAdLHi22V0iWa7pXSqjmfhDzk=; b=TmA69lemswQ3oQw0YfF8M0Yswl2eCklR1bUcKHLEPDt+C1SdqfukrHVHzKbid87LCS yPbJcJby0JeZCiP+gtaRfCrAAyT+s/jFLkwgkMsDMFaVwv9WC35tf5quGXymoM4EELxd XNQbI7/afvupLHH7XECKMK52wZtRxxZzxydYOD2lF9MxJntNYCyP9yBtHUUj8Knm7H2L CAqrprIwTH91cSRGAWrqQlvU0zstrSR2jn6f6nAEU/I48p//lIZ/WQIwjyJ6HeOWv27b 5HScN0+K3VRhw0QDn9p0FW1OpQd3kcn2HyAVf/MAfEJM9RJpg+vJ1Ms4vJpIfBLuSoXm 04Mg== MIME-Version: 1.0 Received: by 2002:adf:f884:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 19:54:14 -0700 (PDT) From: Jim Wilson Date: Tue, 26 Jun 2018 02:54:00 -0000 Message-ID: Subject: RISC-V: decr_pc_after_break causing problems To: gdb@sourceware.org Cc: andrew.burgess@embecosm.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-06/txt/msg00010.txt.bz2 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