有直接使用gdb调试而不是PSoC Creator的方法吗？

您可以使用诸如PrimeExoServer之类的工具来获取被调用的GDB实例的完整命令行。这应该允许你直接使用它。



     以下为原文
  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.

很有趣！如果你设法做到这一点，请张贴你的结果！



     以下为原文
   Interesting! If you manage to make this work, please post your results!

ARM NOE-EABI- GBD.EXE是实际的GDB过程。它的命令行包括用于调试的ELF文件和一组包含源的目录。“解释器＝MI”位告诉GDB格式化它的输出，使得它很容易被程序解析，而不是被一个人坐在键盘上解析。这就是我的样子：
“C： Program Files（x86）   2.2  Cypress PSoC Creator PSoC Creator导入gnu_cs 胳膊 4.4.1  bin臂都是GDB。exe”翻译=米Z 代码   PSoC同步同步。cydsn     sync.elf CortexM3 arm_gcc_441调试D Z：代码   PSoC同步同步。cydsn  generated_source  psoc5 D Z 代码   sync.cydsn PSoC同步三维Z 代码 系统PSoC数控同步。cydsn  TOPDESIGN D Z 代码   PSoC同步同步。cydsn  generated_source
GDB不知道任何关于PSoC或任何单片机为此事。它依赖于另一个进程，谈判委员会（又名“远程目标”）通过USB或什么的。在柏树的世界，我相信是“psoc5debugger .exe”，它显示为子行。这可能意味着，PSoC Creator饲料命令脚本GDB，除其他事项外，执行psoc5debugger.exe。命令行是这样的：
“C：程序文件（x86）/赛普里斯/ PSoC Creator / 2.2/psoc创造者/斌/ cypsoc5debugger .exe”“T”“ppio：dvkprog5 / 00000 f23350c：1“针”cyd2stubpipe712”“噘嘴”stub2cydpipe712”
我猜PPIO：…指的是（-T）“目标”的USB接口？设备和PIN和POUT是I/O流。不幸的是，我不知道怎么GDB实际上是连接到psoc5debugger I/O流。我使用OpenOCD和Segger的J-Link的其他项目都只存在一个TCP / IP服务器套接字，GDB挂钩通过“目标远程主机端口：<；>；”命令。
一个小的信息从柏树如何psoc5debugger工作很长的路要走。我的项目，能够独立调试PSoC Creator是一个很难的要求。我的大部分代码库都是用C++编写的。PSoC Creator不知道如何处理C++，我猜它在柏树的待办事项列表上非常遥远。即使我真的喜欢什么psoc5已经在硬件层面提供，Cypress的IDE根本不会把我的代码。
这是一个真正的失望，因为底层的GNU工具链处理C++是很好的。



     以下为原文
   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)CypressPSoC Creator2.2PSoC Creatorimportgnu_csarm4.4.1binarm-none-eabi-gdb.exe" -interpreter=mi Z:codePSoCsyncsync.cydsnCortexM3ARM_GCC_441Debugsync.elf -d Z:codePSoCsyncsync.cydsnGenerated_SourcePSoC5 -d Z:codePSoCsyncsync.cydsn -d Z:codePSoCsyncsync.cydsnTopDesign -d Z:codePSoCsyncsync.cydsnGenerated_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:" 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.

所以，如果psoc5debugger是GDB子过程，它shjould启动gdb。在这种情况下，你不需要关心它是如何开始的，以及它如何与GDB。你刚开始GDBas Creator。
但命令行看来，这两个过程使用命名管道通信机制：“针”cyd2stubpipe712”“噘嘴”stub2cydpipe712”
我不知道psoc5debugger过程可以运行像gdbserver（你与其他工具链）。



     以下为原文
  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).

你好，
在这个问题上有什么发现？
我现在试图从命令行中使用GDB和PSoC4。
从PSoC Creator开始时的实际命令行如下：
PSoC Creator创作
“C:pSoC创建者\ pSOC创建者BICySPAWAPNAP.exe”-n“Gbd4876VI21”-D:GCC-ARMI-EABI-4Y-2014Q3-20140805-Wi32  Bin  ARM-非EABI -GBD.exe -解释器＝MI“D： U PSOC创建者 SWA70SPILL。CysNNCORTEXM0ARMGGCCL通用版本 SPILL。ELF”
CySpAWAnAPP然后启动“D:BA4B-4201-Q43-20140805-Wi32  BIN  ARM无EABI GDB .exe”-解释器＝MI“D：UPSOC创建者sWA70SPILL。CysNNCORTEXM0ARMGGCCGROULYPROSPORE SPILL。ELF“ARM无EABI GDB然后启动”C: /程序文件（x86）/赛普里斯/PSoC Creator /3.1/PSoC创建//bin /CypSoC4调试器.exe“-t”“pPIO：KITPROG/0A08043602213400 1”“-PIN”“CYD2StuPIPPE-48 76”“-PUT”“Stub2CydPPE48 76”4876是PSoC Creator的PID。注意，不是使用CyPress GCC工具链，而是使用通用工具链。
从命令行中启动所有的ARM NOE-EABI- GBD.EXE都不启动CypSoC4调试器。
所以我想知道ARM ENO EABI GDB是如何启动PypSOC4调试器的，如果在创建者下运行的话！GDB日志记录没有显示任何有用的信息。
有什么想法吗？
哈代



     以下为原文
  Hi,
    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)CypressPSoC Creator3.1PSoC CreatorBINcyspawnapp.exe" -n "GDB_4876_21" -- D:bgccgcc-arm-none-eabi-4_8-2014q3-20140805-win32binarm-none-eabi-gdb.exe  -interpreter=mi "D:uPSoC CreatorSWA70Spiel.cydsnCortexM0ARM_GCC_GenericReleaseSpiel.elf"
              cyspawnapp then starts    
          "D:bgccgcc-arm-none-eabi-4_8-2014q3-20140805-win32binarm-none-eabi-gdb.exe" -interpreter=mi "D:uPSoC CreatorSWA70Spiel.cydsnCortexM0ARM_GCC_GenericReleaseSpiel.elf"    
               
           arm-none-eabi-gdb then starts    
          "C:/Program Files (x86)/Cypress/PSoC Creator/3.1/PSoC Creator/bin/cypsoc4debugger.exe" "-t" "PPIO:KitProg/0A08043602213400:1" "-pin" "Cyd2StubPipe4876" "-pout" "Stub2CydPipe4876"    
   
    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.
    Any ideas?
    Hardy

这里的线索是：目标选择远程| C：/程序文件（x86）/赛普里斯/ PSoC 创造者/ 3.3 / PSoC 创造者/斌/ cypsocdebugger.exe T ppio：kitprog / 091207de002e4400:1
在gdb后加载ELF文件的“文件”：
目标远程|“C：程序文件（x86）/赛普里斯/ PSoC Creator / 4.1/psoc创造者/斌/ cypsocdebugger .exe”T ppio：miniprog3 / 1411dd0000be：1
更换钻头后ppio：与你的硬件调试正确的ID。
这是如何创建子进程GDB调试器，然后与它通过管道。N. B.注意“*”。我一开始就错过了。
我喜欢柏IDE；我只想设置断点并不会正确地做PSoC的创造者4.1。我可以调试我的硬件使用GDB和柏树调试器和设置断点的文件：线数基础上就好。在柏树的IDE，它工作不正常：它说的线数不存在，这是废话。
罗杰



     以下为原文
  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.
    Roger