My feeling is that having not history whatsoever with the project is a good way to got shot down early with such a patch.
On the risk that I repeat myself: I think that for two reasons the default should be reversed. One, from what I can tell on my end there seems to be nothing that is going wrong. Looking through the mentioned thread, that is about failed register reads, not failed memory reads. (Coincidentally I am working with various Cortex-M/STM32 platforms too) I have never encountered those, but also that is definetly something that the gdb user should be made aware of, rather than returning *wrong* values. And that leads to secondly, my main point: The user should be made aware that something is wrong. The current situation means the user gets wrong data and wonders what the heck is going on, only to then maybe going down the rabbit hole and discovering that option, as neither is it common knowledge, nor is failing to read memory a common situation. In the case of e.g. stacktraces throwing (gdbserver related) errors, there is quickly clear that something is wrong, and people will very likely have a look at the openocd logs, where it then could tell about that option being available as a possible remidy of that situation. As for the last question about possible target problems, its a clear yes and no. In what I am doing there is always the possibility of some memory access being denied. Debugging data structures and pointers, sometimes lead to uncharted address space. My gdb plugin is trying to display a lot of information by trying to dereference pointers and look whats there, expecting the high possibility of it going wrong. And last but not least, there are peripheral registers that to the debugger look like memory, which have their own sometimes complicated access rules, and for example accessing them without the proper preconditions locks up the chip, occuring as a read error into gdb, which my plugin then can take as a hint to next time not try to access that peripheral register. In short: there are countless occasions where a failed memory access is a possibility. --- **[tickets:#406] "Failed to read memory" leads to 0 value instead of error message in gdb** **Status:** new **Milestone:** 0.10.0 **Created:** Fri Jun 30, 2023 09:44 AM UTC by PlasmaHH **Last Updated:** Mon Jul 03, 2023 11:23 AM UTC **Owner:** nobody I am using openocd from git commit eebcf3cff with this patch applied: https://github.com/STMicroelectronics/OpenOCD/commit/5bb46921e7ed1376595509c62ad1c48694045c3c Intial log of openocd: ~~~ Open On-Chip Debugger 0.12.0+dev-00246-geebcf3cff-dirty (2023-06-26-14:41) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html DEPRECATED! use 'adapter speed' not 'adapter_khz' Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : STLINK V4J2B1S0 (API v3) VID:PID 0483:3757 Info : Target voltage: 2.501978 Info : Unable to match requested speed 4000 kHz, using 3500 kHz Info : Unable to match requested speed 4000 kHz, using 3500 kHz Info : clock speed 3500 kHz Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x0be12477 Info : [stm32u5x.cpu] Cortex-M33 r0p4 processor detected Info : [stm32u5x.cpu] target has 8 breakpoints, 4 watchpoints Info : starting gdb server for stm32u5x.cpu on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 CPU in Non-Secure state [stm32u5x.cpu] halted due to debug-request, current mode: Thread xPSR: 0x69000000 pc: 0x08005978 msp: 0x2000a4d8 Info : device idcode = 0x20016482 (STM32U57/U58xx - Rev X : 0x2001) Info : TZEN = 0 : TrustZone disabled by option bytes Info : RDP level 0 (0xAA) Info : flash size = 2048 KiB Info : flash mode : dual-bank Info : device idcode = 0x20016482 (STM32U57/U58xx - Rev X : 0x2001) Info : TZEN = 0 : TrustZone disabled by option bytes Info : RDP level 0 (0xAA) Info : flash size = 2048 KiB Info : flash mode : dual-bank Info : device idcode = 0x20016482 (STM32U57/U58xx - Rev X : 0x2001) Info : TZEN = 0 : TrustZone disabled by option bytes Info : RDP level 0 (0xAA) Info : OTP size is 512 bytes, base address is 0x0bfa0000 Error: Failed to read memory at 0x00000000 ~~~ Upon reading any address that is not available instead of getting an error within gdb, I get a value of 0. This is what openocd -d3 says to one of these accesses: ~~~ Debug: 2042 11419 gdb_server.c:375 gdb_log_incoming_packet(): [stm32u5x.cpu] received packet: m7055363,4 Debug: 2043 11419 gdb_server.c:1510 gdb_read_memory_packet(): addr: 0x0000000007055363, len: 0x00000004 Debug: 2044 11419 target.c:2437 target_read_buffer(): reading buffer of 4 byte at 0x07055363 Debug: 2045 11419 stlink_usb.c:1120 stlink_usb_error_check(): STLINK_SWD_AP_WDATA_ERROR Error: 2046 11420 arm_adi_v5.c:570 mem_ap_read(): Failed to read memory at 0x07055363 Debug: 2047 11420 gdb_server.c:391 gdb_log_outgoing_packet(): [stm32u5x.cpu] sending packet: $00000000#80 ~~~ --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
