Author Topic: SOLVED Debugger does not pauses/stops the target (via GDB)  (Read 7160 times)

Offline MasterAlexei

  • Multiple posting newcomer
  • *
  • Posts: 77
    • Fun electronic
SOLVED Debugger does not pauses/stops the target (via GDB)
« on: February 01, 2014, 04:38:19 pm »
Hello CB Team,

I do use the CB to develop some embedded stuff, and trying to debug them. The dubber works fine, until I try to pause or stop the target (everything else works fine). On that place the Debugger Plugin should sent Ctrl+C to the GDB, but it does not.

I did some researches, and find out that, on line 1631 in file debuggergdb.cpp (Rev. 9410),
where the condition is checked "if (pid > 0)" the pid is <= 0, and it does not enter the clause to send the Ctrl+C.
I use the GDB from gcc-arm-none-eabi 4.8, and SEGGER J-Link with its GDB Server.
With the yagarto 4.7.2 I did not have such problem, put it is old for my target, and I need to use gcc-arm-none-eabi 4.8.

Is it possible to fix that problem?

Thanks in advance,

Alexey

« Last Edit: February 01, 2014, 06:40:57 pm by MasterAlexei »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #1 on: February 01, 2014, 05:09:19 pm »
What OS/distro are you using?

Can you post the full log from the debugger?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #2 on: February 01, 2014, 05:11:29 pm »
Also are you using the interface for remote debugging, instead of manually specifying connection commands?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MasterAlexei

  • Multiple posting newcomer
  • *
  • Posts: 77
    • Fun electronic
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #3 on: February 01, 2014, 05:19:16 pm »
What OS/distro are you using?

Can you post the full log from the debugger?

Sorry, did forget it.
The OS WinXP, C::B Rev 9410, against wxWdg 2.8.12
I am using the SEGGER J-Link with its GDB Server Version 4.80c, the last one. The commands for it are the following:
Code: [Select]
target remote localhost:2331
monitor flash device = STM32F429ZI
monitor flash download = 1
monitor flash breakpoints = 1
monitor reset
load
monitor reset
Debug Log
Code: [Select]
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: D:\MyProjects\ARM\STM32\STM_LogicAnalyser\
Adding source dir: D:\MyProjects\
Adding file: D:\MyProjects\ARM\STM32\STM_LogicAnalyser\bin\Debug\STM_LogicAnalyser.elf
Changing directory to: D:/MyProjects/ARM/STM32/STM_LogicAnalyser/.
Set variable: PATH=.;D:\Soft\SDKs\ARM\gcc-arm-none-eabi-4_8\arm-none-eabi\lib\thumb;D:\Soft\SDKs\ARM\gcc-arm-none-eabi-4_8\bin;D:\Soft\SDKs\ARM\gcc-arm-none-eabi-4_8;D:\Soft\SDKs\MinGW\bin;D:\Soft\SDKs\MinGW;D:\Soft\SDKs\Xilinx\ISE10.1\EDK\bin\nt;D:\Soft\SDKs\Xilinx\ISE10.1\EDK\lib\nt;D:\Soft\SDKs\Xilinx\ISE10.1\ISE\bin\nt;D:\Soft\SDKs\Xilinx\ISE10.1\ISE\lib\nt;D:\Soft\SDKs\Xilinx\ISE10.1\ISE\smartmodel\nt\installed_nt\lib\pcnt.lib;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;D:\Soft\SDKs\Xilinx\ISE10.1\ChipScope\bin\nt;d:\Soft\Media\MKVToolNix;C:\Programme\ATI Technologies\ATI.ACE\Core-Static;D:\Soft\MySQL\MySQL Server 5.1\bin;C:\Programme\IVI Foundation\VISA\WinNT\Bin;C:\Programme\TortoiseSVN\bin;D:\Soft\SDKs\ARM\SAM-BA v2.10\drv;D:\Soft\SDKs\ARM\SAM-BA v2.10;c:\cygwin\bin;D:\Soft\SDKs\wxWidgets-2.8.10\lib\gcc_dll;D:\Soft\SDKs\Svn\bin;d:\Soft\Lame

[debug]Command-line: D:\Soft\SDKs\ARM\gcc-arm-none-eabi-4_8\bin\arm-none-eabi-gdb.exe -nx -fullname  -quiet  -args D:/MyProjects/ARM/STM32/STM_LogicAnalyser/bin/Debug/STM_LogicAnalyser.elf
[debug]Working dir : D:\MyProjects\ARM\STM32\STM_LogicAnalyser

Starting debugger: D:\Soft\SDKs\ARM\gcc-arm-none-eabi-4_8\bin\arm-none-eabi-gdb.exe -nx -fullname  -quiet  -args D:/MyProjects/ARM/STM32/STM_LogicAnalyser/bin/Debug/STM_LogicAnalyser.elf
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from D:\MyProjects\ARM\STM32\STM_LogicAnalyser\bin\Debug\STM_LogicAnalyser.elf...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs
[debug]Copyright (C) 2013 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "--host=i586-mingw32 --target=arm-none-eabi".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]A syntax error in expression, near `new-console on'.
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source D:\Soft\SDKs\CodeBlocksSVN\CodeBlocksSrc\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/MyProjects/ARM/STM32/STM_LogicAnalyser/
[debug]Source directories searched: D:/MyProjects/ARM/STM32/STM_LogicAnalyser;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> directory D:/MyProjects/
[debug]Source directories searched: D:/MyProjects;D:/MyProjects/ARM/STM32/STM_LogicAnalyser;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> target remote localhost:2331
[debug]Remote debugging using localhost:2331
[debug]0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> monitor flash device = STM32F429ZI

In ?? () ()

[debug]> monitor flash device = STM32F429ZI
[debug]Selecting device: STM32F429ZI
[debug]Selecting device: STM32F429ZI
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> monitor flash download = 1
[debug]Flash download enabled
[debug]>>>>>>cb_gdb:
[debug]> monitor flash breakpoints = 1
[debug]Flash breakpoints enabled
[debug]>>>>>>cb_gdb:
[debug]> monitor reset
[debug]Resetting target
[debug]>>>>>>cb_gdb:
[debug]> load
[debug]Loading section .text, size 0x16654 lma 0x8000000
[debug]Loading section .ctors_dtors, size 0x8 lma 0x8016654
[debug]Loading section .relocate, size 0x918 lma 0x801665c
[debug]Loading section .ARM.extab, size 0x178 lma 0x8017f9c
[debug]Loading section .ARM.exidx, size 0x228 lma 0x8018114
[debug]Start address 0x8004c20, load size 94996
[debug]Transfer rate: 759968 bits in <1 sec, 9499 bytes/write.
[debug]>>>>>>cb_gdb:
[debug]> monitor reset
[debug]Resetting target
[debug]>>>>>>cb_gdb:
[debug]> info locals
[debug]pulSrc = 0x0
[debug]pulDest = 0x0
[debug]cnt = 0
[debug]idx = 0
[debug]>>>>>>cb_gdb:
[debug]> info args
[debug]No arguments.
[debug]>>>>>>cb_gdb:
[debug]> info registers
[debug]r0             0x0 0
[debug]r1             0x0 0
[debug]r2             0x0 0
[debug]r3             0x0 0
[debug]r4             0x0 0
[debug]r5             0x0 0
[debug]r6             0x0 0
[debug]r7             0x0 0
[debug]r8             0x0 0
[debug]r9             0x0 0
[debug]r10            0x0 0
[debug]r11            0x0 0
[debug]r12            0x0 0
[debug]sp             0x0 0x0
[debug]lr             0x0 0
[debug]pc             0x8004c20 0x8004c20 <Default_Reset_Handler>
[debug]xpsr           0x1000000 16777216
[debug]MSP            0x1000ffe0 268500960
[debug]PSP            0x0 0
[debug]PRIMASK        0x0 0
[debug]BASEPRI        0x0 0
[debug]FAULTMASK      0x0 0
[debug]CONTROL        0x2 2
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  Default_Reset_Handler () at src\board\startup_stm32f4xx.c:292
[debug]>>>>>>cb_gdb:
[debug]> x/32xb 0x0
[debug]0x0: 0x00 0x00 0x01 0x10 0x21 0x4c 0x00 0x08
[debug]0x8: 0x21 0x4d 0x00 0x08 0x31 0x4d 0x00 0x08
[debug]0x10: 0x41 0x4d 0x00 0x08 0x51 0x4d 0x00 0x08
[debug]0x18: 0x61 0x4d 0x00 0x08 0x00 0x00 0x00 0x00
[debug]>>>>>>cb_gdb:

Continuing...

[debug]> continue
[debug]Continuing.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #4 on: February 01, 2014, 06:05:44 pm »
Have you put the commands in the initial commands field?
If you have then, C::B doesn't know you're in remote debugging mode and does the wrong thing when trying to break the inferior.

Go to Project -> Properties -> Debugger -> Remote debugging and set the connection from there.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MasterAlexei

  • Multiple posting newcomer
  • *
  • Posts: 77
    • Fun electronic
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #5 on: February 01, 2014, 06:21:21 pm »
Have you put the commands in the initial commands field?
If you have then, C::B doesn't know you're in remote debugging mode and does the wrong thing when trying to break the inferior.

Go to Project -> Properties -> Debugger -> Remote debugging and set the connection from there.
That is the way i do almost 3 years already. As I already said, with the yagarto 4.7.2 gdb it works fine, with the newest gcc gdb 4.8 it does not. What I remembered yet is that for two years I did some changes in the debuggergdb plugin of C::B which does not hide the console window of the gdb. And this did work at that time, but since some revisions it was not necessary anymore. It seems that it will be necessary now.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12086
    • Travis build status
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #6 on: February 01, 2014, 06:25:47 pm »
But if you've setup the remote debugging then m_State.GetDriver()->UseDebugBreakProcess() should return false and then you won't hit line 1631, but line 1646.
Is this the case?

As far as I remember, I was able to hide the console window, back in then when I've implemented this feature.
Also I don't think there are any changes to the handling of remote debugging lately (last 6 months).

Lastly: If you have any patches, it might be good idea to show them, so we can try to integrate them in the official release.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MasterAlexei

  • Multiple posting newcomer
  • *
  • Posts: 77
    • Fun electronic
Re: Debugger does not pauses/stops the target (via GDB)
« Reply #7 on: February 01, 2014, 06:39:30 pm »
But if you've setup the remote debugging then m_State.GetDriver()->UseDebugBreakProcess() should return false and then you won't hit line 1631, but line 1646.
Is this the case?

As far as I remember, I was able to hide the console window, back in then when I've implemented this feature.
Also I don't think there are any changes to the handling of remote debugging lately (last 6 months).

Lastly: If you have any patches, it might be good idea to show them, so we can try to integrate them in the official release.
Well, I must say, that this was my mistake here. :) I did not put the localhost:2331 in to the fields IP Address:... Port:... that is why plugin thought, that this is not remote target.
I did fill that fields with the info and now it works!
Thanks for that info!
Sorry one more time for that mistake.

I think, I can mark that thread as solved.