Yes, under the hood all the GUIs use gdb plus a "gdb server" to connect to the debug probe. They often seem to send the same text commands that a terminal user would.
I started tracing/printing the extended-remote protocol packets going between gdb and the stlink gdb server.
By accident, I partially figured out one issue (it still does not work). In the case of setting memory and printing addresses with gdb and ST's gdb server, it turns out that ST's gdb server needs killed and restarted every single debug session. (and possibly every time the MCU is reset?) (this "fix" does not actually make the issue go away, it just delays it)
gdb can start with the ability to print and set memory addresses (if any only if the debug server is restarted each debug session), but gdb looses the ability to set and print addresses once the "continue" command is issued.
For some reason, communicating with the stlink gdb server changes the "mode/state" that gdb is in and cause it to start rejecting valid commands with "unexpected token" errors*
//After connecting to stlink gdb server with target extended-remote :61234
//This command is rejected and no packets related to this command are sent to the gdb server
(gdb) set {int}0x20000000 = 123
unexpected token
(gdb) print {int}0x20000000
unexpected token
whereas after restarting stlink gdb server it initially works, and then stops working after typing continue
//After connecting to stlink gdb server with target extended-remote :61234
//This command is accepted and several packets related to this command are sent to the gdb server
(gdb) set {int}0x20000000 = 123
//It Works!
(gdb) print {int}0x20000000
$1 = 123
//But only before the MCU executes its first instruction
(gdb) continue
//Then either interrupt to get the prompt back with control-C or wait until you hit a breakpoint
//This breaks it for some reason
(gdb) set {int}0x20000000 = 123
unexpected token
(gdb) print {int}0x20000000
unexpected token
it still does not work, but it is a small step in the right direction
gdb 14.2 compiled from source
stlink gdb server 7.9.0
Footnote, tips for debugging stlink gdb server -> gdb
- in gdb set `set debug remote 1` - this will show the presence or lack of packets going from gdb to stlink gdb server
- in stlink server's config.txt enable verbose mode and all logging and give it a valid path to write the logfile (not really needed if you "set debug remote 1" in gdb)
search tags: STM32 gdb server unexpected token error, target remote, extended-remote