duaneellissd
commented
1 year ago On an embedded system, this would be the most horrible thing ever.
On a Linux platform - The GDB interface is ptrace(), and if the debugger attempts to access invalid memory that error situation is well thought out and functions nicely as you would expect. In that case, GDB displays some message like: "invalid memory location"
In contrast, the embedded world is very different. There is no PTRACE, instead the GDB SERVER that is your JTAG box would (really COULD) cause a hardware memory access an invalid pointer, this causes no end of other issues an d problems like BUS FAULTS, MMU FAULTS, the list of problems and combinations endless and not pleasant to deal with.
You could argue that the problem is in the jtag debugger/gdb-server - aka: OPenOCD or PYJTAG, or STM32_STLINK, or SEGGER probes. But there are many of these, and each one of these work very differently.
Fixing this would require getting multiple vendors to agree (no simple task) and to coordinate a means for hardware developers to fix things in their chips and their board. Some of this is just not fixable. For example if an ARM CORE flags an INVALID POINTER exception, the next time you step the cpu it will goto the trap handler. ARM is not and will not add a feature to disable this.
The problem is - in many cases, this cannot be fixed by the jtag tool (like OPENOCD, or PYJTAG, or others, like SEGGER) because every type of embedded hardware is very different. The list of things to "correct or fix" is different for every board, every RTOS support package, in the embedded world this is endless and highly custom to the specific platform.
I am not saying this is a bad feature - I sort of like it and have used this before - but I have also been bitten very badly by this bug in the past.
If this feature was present - it should be DISABLED by default, with a GAINT DEVELOPER warning not to make the ENBABLED By default because you will cause many many embedded developers problems just by moving the mouse across the screen and hovering over something.
Is your feature request related to a problem? Please describe. When I hover over a char * pointer I get a 'click to explore memory at' prompt. However I've got a ton of linked lists I'm burrowing in and limited screen space.
Describe the solution you'd like It would be nice if I get the first 16-32 bytes visible on the hover prompt so I don't have to scroll all the way down to the memory window.