You can use tools like e.g. ProcessExplorer to get the complete commandline of the called gdb instance. That should allow you to use it directly.
arm-none-eabi-gdb.exe is the actual GDB process. It's command line consists of the .elf file for debugging and a bunch of include directories for source. The "interpreter=mi" bit tells GDB to format it's output so that it's easy to parse by a program, rather than being parsed by a human being sitting at a keyboard. Here's what mine looks like:
"C:\Program Files (x86)\Cypress\PSoC Creator\2.2\PSoC Creator\import\gnu_cs\arm\4.4.1\bin\arm-none-eabi-gdb.exe" -interpreter=mi Z:\code\PSoC\sync\sync.cydsn\CortexM3\ARM_GCC_441\Debug\sync.elf -d Z:\code\PSoC\sync\sync.cydsn\Generated_Source\PSoC5 -d Z:\code\PSoC\sync\sync.cydsn -d Z:\code\PSoC\sync\sync.cydsn\TopDesign -d Z:\code\PSoC\sync\sync.cydsn\Generated_Source
GDB doesn't know anything about PSoC or any mcu for that matter. It relies on another process that talks to the board (aka the "remote target") via USB or whatever. In the Cypress world, I believe that process is "psoc5debugger.exe", which shows up as a subprocess of GDB. That probably means that PSoC creator feeds a command script to GDB which among other things, executes psoc5debugger.exe. The command line is something like this:
"C:/Program Files (x86)/Cypress/PSoC Creator/2.2/PSoC Creator/bin/cypsoc5debugger.exe" "-t" "PPIO:DVKProg5/00000F23350C:1" "-pin" "Cyd2StubPipe712" "-pout" "Stub2CydPipe712"
I'd guess that the PPIO:... thing refers to the USB interface of the (-t for "target"?) device and that -pin and -pout are I/O streams. Unfortunately, I don't know how GDB is actually hooking up to the psoc5debugger I/O streams. I've used openocd and Segger's J-Link for other projects and they simply present a TCP/IP server socket that GDB hooks up to via a "target remote localhost:<port>" command.
A little information from Cypress about how psoc5debugger works would go a long way. For my project, being able to debug independently of PSoC Creator is a hard requirement. Most of my codebase is written in C++. PSoC Creator doesn't know what to do with C++, and I'd guess that it's pretty far down on Cypress' to-do list. Even though I really like what PSoC5 has to offer at the hardware level, Cypress' IDE simply won't handle my code.
This is a real disappointment becuase the underlying GNU toolchain handles C++ just fine.
So if the psoc5debugger is a sub-process of GDB, it shjould be started by GDB. In that case, you don't need to care about how to start it, and how it communicates with GDB. You just start GDB as Creator does.
But the command line looks as if the two processes use named pipes as communication mechanism:
"-pin" "Cyd2StubPipe712" "-pout" "Stub2CydPipe712"
I don't know whether the psoc5debugger process can be run like a GDBServer (as you did with other tool chains).
any findings on this issue?
I'm currently trying to use gdb in conjunction with psoc4 from the command line.
The actual command lines when started from PSoC Creator are as follows:
PSoC Creator creates
"C:\Program Files (x86)\Cypress\PSoC Creator\3.1\PSoC Creator\BIN\cyspawnapp.exe" -n "GDB_4876_21" -- D:\b\gcc\gcc-arm-none-eabi-4_8-2014q3-20140805-win32\bin\arm-none-eabi-gdb.exe -interpreter=mi "D:\u\PSoC Creator\SWA70\Spiel.cydsn\CortexM0\ARM_GCC_Generic\Release\Spiel.elf"
4876 is the PID of PSoC Creator. Notice that not the cypress GCC toolchain is used, instead a generic one.
Starting just the arm-none-eabi-gdb.exe with all its arguments from the command line does not start cypsoc4debugger.
So I'm wondering how arm-none-eabi-gdb starts pypsoc4debugger if running under the Creator!? gdb logging does not reveal anything useful.
I re-built gdb from source, using pretty much the configuration flags shown with the "show configuration" command. I added a bit of code to log the MI commands received by GDB to a file, so that we can see how PSoC Creator interacts with GDB. Here's an example of MI commands for a simple debug session:
I then tried to run gdb directly...
> arm-none-eabi-gdb.exe "c:\Users\simark-vm\Documents\PSoC Creator\Workspace01\Marc-AndreDesign02.cydsn\CortexM3\ARM_GCC_493\Debug\Marc-AndreDesign02.elf"
And ran the CLI equivalent of the -target-select command used by PSoC Creator:
(gdb) target remote | C:/Program\ Files\ (x86)/Cypress/PSoC\ Creator/3.3/PSoC\ Creator/bin/cypsocdebugger.exe -t PPIO:KitProg/091207DE002E4400:1
The response was "Unknown remote qXfer reply: OK". I then tried the command a second time, and this time it worked! I am now able to step in the code using command line GDB. I tried modifying memory, adding a watchpoint, it worked well.
I then tried to disconnect and reconnect my dev board, to see if I could do it again. This time I was given:
The target device 'PPIO:KitProg/091207DE002E4400:1' could not be found. Remote communication error. Target disconnected.: No error.
The difference between the two runs is that the first time, I had started a debug session previously using PSoC Creator, so the debug session was still up. Starting a new instance of cypsocdebugger.exe probably only picked up the already setup session. I don't know why I got the "Unknown remote qXfer reply: OK" response though. More work would be needed to be able to start a debug session from scratch, without invloving PSoC Creator at all.
The clue is here:
-target-select remote | C:/Program\ Files\ (x86)/Cypress/PSoC\ Creator/3.3/PSoC\ Creator/bin/cypsocdebugger.exe -t PPIO:KitProg/091207DE002E4400:1
In gdb after loading elf file with "file" do:
target remote | "C:/Program Files (x86)/Cypress/PSoC Creator/4.1/PSoC Creator/bin/cypsocdebugger.exe" -t PPIO:MiniProg3/1411DD0000BE:1
Replace the bit after PPIO: with the right ID for you hardware debugger.
This is how gdb creates the debugger child process and then communicates with it through a pipe. N.B. Note the "|". I missed it at first.
I like the Cypress IDE; I just want it to set breakpoints and it won't do it properly in PSoC Creator 4.1. I can debug my hardware using gdb and the Cypress debugger and it sets breakpoints on a file:line-number basis just fine. In the Cypress IDE it does not work properly: it says the line number does not exists which is nonsense.