From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 85EAB3842AE5 for ; Wed, 29 Jun 2022 17:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85EAB3842AE5 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 6B12571DA2; Wed, 29 Jun 2022 17:54:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LY8Gm2KNHz4V20; Wed, 29 Jun 2022 17:54:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656525248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CSsoLV5uhyDGFuQVEoIqNEdl4oUk2ZyrPuNfqSMNoAU=; b=VpotGssUWe/XRvccQx0wzpwb/WtWFDd2Y7s8j9Qx0X61+mHxxSB7A9De4vQrXpYx6OeOZJ 2Hy1/L9Ao5RhAO3gwu3p13cAkgKN2S7B7c7CN+j+WWO1DBLQC2RMBYi2h52Bt5/DogmlXd XUYRMg58W7IawLtfHFGsO38/wO1rMFzewWB74sXr+4x3yELSY1irxk+H1cxLzHH5TIJvgT qVXtg3gJssdUuE/6KXjrPwKw1J8YnqZxC99/z4b6kPCFzxFA6NhvWGEgxaqrcdNdrtJ0gt EBCOdEvw8/BBTUHfIp1MC9jBa9oQhFCHUWdg1Uhipgn5ggiD5gaVHlFe2lzF4Q== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B3ED3E276; Wed, 29 Jun 2022 17:54:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 29 Jun 2022 10:54:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: gdb for Riscv, single stepping issue Content-Language: en-US To: Pedro Alves , James Becker , gdb@sourceware.org References: <069ae440-5fc5-b853-e415-e9643e6d8144@FreeBSD.org> <6068e741-8f0f-53b3-0664-548a4930d92c@palves.net> From: John Baldwin In-Reply-To: <6068e741-8f0f-53b3-0664-548a4930d92c@palves.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656525248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CSsoLV5uhyDGFuQVEoIqNEdl4oUk2ZyrPuNfqSMNoAU=; b=jULciV/Uft+6mEmk4X3MwXZauky1OBSEZoDXcJ/l7Kekz8ZBfI1+mKA8c+yzNdGYHCe5uj PohfQQaHQkRm25kFml47OOJN9jJ7hNB4QznEIcvHVkDvSgnA/Atp174Oxxq5Y1oOihFq/p BUQcDB7TF0OlP3dhGj/roAIwKR1Zeys6ED88PjJeSOydFUfymufSczsNmiINSug6cszuEJ 82DBs6goEdSF6zOWkZtyAQl+w1umQo3JxSrNk1tYbrazx0OUIUNYByfcGNMdjIrYDtkTQf RL4MnOwx8f3g5Qn3azmTi2Wxe/wBu/eU6fQC2SHNXhOUbDKT+pF0C2TyOOzfYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656525248; a=rsa-sha256; cv=none; b=yVwrLTG2cV0gJJ93BYur5PYROaBSDVJNsGHJ+TVZBUlEJTJrBZzwInOjszF49v0eu1TaHh Of1Y9rxqByXNrV+kOAfPOhaPJEkes2B7ugknVZzMOWIQZESXdHdOhd784utff/+5wBVu3K ncZasLkNe9yH72Yvfy8ZdrTIJiN/j/r93rIyvYE7fh7l+xuaCn57oNrYF5GDkOnpPAqKgg oYTE3zlq+Ng48gYq2wpYHfsErK4PDqmNuGJorr2tmLqypfQ1o47STt+VsHjVHFWfRAU13L XLTdMYKmu0Q+Q0WyDn63eKe2xkht8YvIKSO2AJGx7S8CnVZiRLC9rd5iPK3H/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2022 17:54:12 -0000 On 6/29/22 2:34 AM, Pedro Alves wrote: > On 2022-06-28 16:52, John Baldwin wrote: >> On 6/27/22 1:40 PM, James Becker wrote: >>> Hello, >>> >>> I have a RISCV-EL2 core running in a Nexys A7 FPGA board. >>> >>> I have openocd for riscv running over jtag with a connection by >>> riscv-gdb to the openocd instance at port 3333. >>> >>> Everything works fine, stepping, break points, load, view memory. >>> >>> But I have one issue: Some of the memory in my design is 4 byte >>> aligned.  Its designed for fast instruction fetch, its known as ICCM. >>> >>> When I have code running in that memory, gdb still works fine for >>> breakpoints, but it will not single step. >>> >>> Looking at the openocd debug files, it appears that gdb is attempting to >>> do a 2 byte read as a part of the single stepping procedure. >>> >>> Since my memory does not support 2 byte reads or writes, this fails. >>> >>> Is there some way that gdb can be configured to not do any 2-byte word >>> reads or writes during single stepping?  I can't seem to find any. >> >> Hmm, setting breakpoints tries to read 1 byte at a time unless you have >> disabled compressed breakpoints.  It looks like as a local hack you could >> change use-compressed-breakpoints to just read 4 bytes rather than 2 >> initially?  Perhaps this is upstreamable if you make it read 4 bytes if >> the target address is 4 byte aligned and only fall back to reading 2 bytes >> if it isn't? >> > > Is that from riscv_breakpoint_kind_from_pc? That uses target_read_code, > so I'd think that since it goes via the code cache, it would read a whole > cache line at once, meaning 64 bytes (show code-cache, show dcache line-size). > > OTOH, riscv_insn::fetch_instruction uses target_read_memory to read 2 bytes, > so I wonder whether this is the access in question: > > /* All insns are at least 16 bits. */ > status = target_read_memory (addr, buf, 2); > if (status) > memory_error (TARGET_XFER_E_IO, addr); > > Why is this using target_read_memory instead of target_read_code, though? > If it did that, then the code cache would be involved here too, papering over > the issue, presumably. > > Curious that the Riscv stub behaves this way, though. I mean, failing the > access instead of reading in aligned 4 bytes chunks, and doing read-modify-write, > if necessary, hiding the issue from GDB. Even inf-ptrace.c handles unaligned > reads/writes and shorter-than-word-sized reads/writes itself, like: > > static ULONGEST > inf_ptrace_peek_poke (ptid_t ptid, gdb_byte *readbuf, > const gdb_byte *writebuf, > ULONGEST addr, ULONGEST len) > { > ... > /* We transfer aligned words. Thus align ADDR down to a word > boundary and determine how many bytes to skip at the > beginning. */ > ... > /* Read the word, also when doing a partial word write. */ > if (readbuf != NULL || chunk < sizeof (PTRACE_TYPE_RET)) > { > > > I guess this also affects the "x" command at least (e.g., "x/2b $pc"), since that > doesn't use the code cache either. Yes, I had reworked my e-mail part way through and I really meant to talk about this code, not the breakpoint code. I agree that target_read_code is probably more correct in fetch_instruction and would in this case hide the odd behavior of the stub: diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c index 69f2123dcdb..09b2599e958 100644 --- a/gdb/riscv-tdep.c +++ b/gdb/riscv-tdep.c @@ -1661,7 +1661,7 @@ riscv_insn::fetch_instruction (struct gdbarch *gdbarch, int instlen, status; /* All insns are at least 16 bits. */ - status = target_read_memory (addr, buf, 2); + status = target_read_code (addr, buf, 2); if (status) memory_error (TARGET_XFER_E_IO, addr); @@ -1672,7 +1672,7 @@ riscv_insn::fetch_instruction (struct gdbarch *gdbarch, if (instlen > 2) { - status = target_read_memory (addr + 2, buf + 2, instlen - 2); + status = target_read_code (addr + 2, buf + 2, instlen - 2); if (status) memory_error (TARGET_XFER_E_IO, addr + 2); } -- John Baldwin