Community
Participate
Working Groups
The startup procedure is not really ideal for debugging Hardware, gdb can detect useful information from the binary (and symbols). Like getting information about the architecture or embedded gdb scripts. The prefered way should be to add as much information to the gdb commandline as possible. for example this procedure will work better then the current configurations allow: ------------------------------------------------------ # start gdb with the executeable and symbols gdb-multiarch -se 'path_to/stm32_uartinit' # Connect to the hardware - this would fail if the architecture is wrong! target remote | openocd -c "gdb_port pipe; log_output /tmp/openocd.log" -f board/stm32f3discovery.cfg # load the binary (and symbols) load # start the application continue ------------------------------------------------------ Configuring a GDB Hardware configuration will currently start gdb "plain" and only add the path later. This is somewhat ackward and not similar to how you would normally use gdb, aside from disallowing gdb to fetch information from the program early and configure itself correctly. For ARM, this means for example to write a script that starts gdb-multiarch with -iex "set architecture arm" appended, otherwise the load command will fail It would be more robust to delegate as much as possibly to gdb, maybe even add some of the setup commands via iex/ex arguments. Another advantage would be to be able to directly use the commandline for debugging via console or other GUIs
Hi Norbert, Thanks for registering this enhancement request. It's true that the way this works now is not ideal, and can be improved. FYI, we have started looking into implementing a new type of debug sessions, that would permit CDT just taking-over an existing GDB session. This is the opposite of the way we launch debug sessions today, where CDT rigidly controls all the details of how the session is launched, according to the launch configuration. Instead, we would use an existing GDB session and attempt to auto-discover how it's configured, whenever it impacts the behavior (i.e. is it all-stop vs non-stop mode, local vs remote, and so on), so that CDT can present a coherent UI. In cases like yours, it would mean that you would have the option to setup a session manually (or with scripts) outside of CDT, configured just the way you like it, and then have CDT take it over, with no or minimal configuration (that's the hope anyway). BTW, this effort does not preclude also doing improvements to existing launches.
The most common cases I use are: * Debug Arm Hardware with gdb-multiarch * Debug via Valgrind (see: https://bugs.eclipse.org/bugs/attachment.cgi?id=266306) Even if it sounded differently, but I would always prefer being able to start a debug session directly from the UI (with one click). So the "attach to session" surely is a nice feature, but more often I need the opposite approach: start a gdb session like under eclipse (primary if something aint working right there) If you want to make me really happy, allow debug configuration with multiple steps - like launch groups, but in a single configuration with access to the settings via variables. This could be used for starting a gdb server, or running the app under valgrind (see attachment above): Step 1: valgrind --leak-check=full --track-origins=yes --vgdb-error=0 ${debugexe} ${debugargs} Step final: gdb-multiarch ${gdbconfig} -se=${debugexe} -ex="target remote | vgdb --wait=3 --pid=${step1pid}" (gdbconfig would be the flags from the settings dialog, like setting search paths and so on)
