From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by sourceware.org (Postfix) with ESMTPS id 333BE3851ABE for ; Wed, 29 Jun 2022 09:34:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 333BE3851ABE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f50.google.com with SMTP id q9so21519309wrd.8 for ; Wed, 29 Jun 2022 02:34:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=CeZkmckVU2jqY8L23rzVq/nVEKYXOEVtrM2val2/2Ac=; b=F6TY5PGc8HL2TrFVg+wHXuvaPnU5eXfLdXwx40slAe4kUkKVIlnF5H/8GSQIUu20N5 4rJZh7GFPNyhalYiLHz2f3yIjwDFGFnSzp3XAibR4zgaMS5qlN7DgeDI55nJAdgXkeRS IVcPJ7h+On/E6mB+Z7EVyQ/ffh9ENyYLW9ju69CyXu3iFuQfOyOLPBrUvCmQED3rw9eS oJhfeMtSuoKtSTo1yCwoySvk8GyH2WpC5SVcVA3J/nrZDfHe2OWaPjTgGB6QFRkIhl0y Pjktvgh6+j8UOXO+V3E9OP6mtXSSlz79Tq2Rvd1higLsuet2p4LOOIeRz6tjO0slF4eH EZPg== X-Gm-Message-State: AJIora9CLgt1NvmIPIxVz0T61HfEF4uFxdGdKMZ3OK7haX9UDuISiqWh HVdDwGok+14/zNFu+sCXD2OjMVpuanE= X-Google-Smtp-Source: AGRyM1tkES3RBj6SVsJEJ71ITyWnW8bcwTNzrwEnY4bPWnJdd+Gln2YBvPhrZUf90oZkAWwnibnBBQ== X-Received: by 2002:a5d:534e:0:b0:21b:adf3:dc19 with SMTP id t14-20020a5d534e000000b0021badf3dc19mr1994021wrv.543.1656495265895; Wed, 29 Jun 2022 02:34:25 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id g13-20020adffc8d000000b0021b99efceb6sm16164792wrr.22.2022.06.29.02.34.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jun 2022 02:34:25 -0700 (PDT) Message-ID: <6068e741-8f0f-53b3-0664-548a4930d92c@palves.net> Date: Wed, 29 Jun 2022 10:34:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: gdb for Riscv, single stepping issue Content-Language: en-US To: John Baldwin , James Becker , gdb@sourceware.org References: <069ae440-5fc5-b853-e415-e9643e6d8144@FreeBSD.org> From: Pedro Alves In-Reply-To: <069ae440-5fc5-b853-e415-e9643e6d8144@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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 09:34:28 -0000 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.