GNU Arm Embedded Toolchain

GDB - create breakpoints with absolute path doesn't work

Asked by andre

I'm using the gdb from within Code::Blocks
It seems, that Code::Blocks creates the Breakpoints always with absolute Paths to the sourcefile which causes an Error in GDB:

#######################################################################################

Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\andre\Projekte\STM32F4-Test\
Adding source dir: C:\Users\andre\Projekte\STM32F4-Test\
Adding file: C:\Users\andre\Projekte\STM32F4-Test\bin\Debug\STM32F4-Test.elf
Changing directory to: C:/Users/andre/Projekte/STM32F4-Test/

[debug]PATH=.;C:\Program Files (x86)\GNU Tools ARM Embedded\4.6 2012q1\bin;C:\Program Files (x86)\GNU Tools ARM Embedded\4.6 2012q1;C:\Program Files (x86)\Microchip\mplabc18\v3.40\mpasm;C:\Program Files (x86)\Microchip\mplabc18\v3.40\bin;C:\Program Files\ImageMagick-6.7.3-Q16;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\MATLAB\R2010a Student\bin;C:\Program Files (x86)\yagarto\bin;C:\Program Files (x86)\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin;C:\Program Files (x86)\Microchip\mcc18\mpasm;C:\Program Files (x86)\Microchip\mcc18\bin;C:\Program Files (x86)\Java\jre6\bin
[debug]Command-line: C:\Program Files (x86)\GNU Tools ARM Embedded\4.6 2012q1\bin\arm-none-eabi-gdb.exe -nx -fullname -quiet -readnow -args C:/Users/andre/Projekte/STM32F4-Test/bin/Debug/STM32F4-Test.elf
[debug]Working dir : C:\Users\andre\Projekte\STM32F4-Test

Starting debugger: C:\Program Files (x86)\GNU Tools ARM Embedded\4.6 2012q1\bin\arm-none-eabi-gdb.exe -nx -fullname -quiet -readnow -args C:/Users/andre/Projekte/STM32F4-Test/bin/Debug/STM32F4-Test.elf
done

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

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints

[debug]Reading symbols from C:/Users/andre/Projekte/STM32F4-Test/bin/Debug/STM32F4-Test.elf...expanding to full symbols...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GNU Tools for ARM Embedded Processors) 7.3.1.20120316-cvs
[debug]Copyright (C) 2011 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.3.1.20120316-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 debugevents on
[debug]No symbol "debugevents" in current context.
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> source C:\Program Files (x86)\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/andre/Projekte/STM32F4-Test/
[debug]>>>>>>cb_gdb:
[debug]> set tdesc filename gdb-conf.xml
[debug]>>>>>>cb_gdb:
[debug]> target remote tcp:localhost:61234
[debug]Reset_Handler () at startup_stm32f4xx.S:70
[debug]C:/Users/andre/Projekte/STM32F4-Test/startup_stm32f4xx.S:70:2865:beg:0x80026ba
[debug]>>>>>>cb_gdb:

Connected

[debug]> load

At C:/Users/andre/Projekte/STM32F4-Test/startup_stm32f4xx.S:70

[debug]> load
[debug]Loading section .isr_vector, size 0x188 lma 0x8000000
[debug]Loading section .text, size 0x2874 lma 0x8000188
[debug]Loading section .ARM, size 0x8 lma 0x80029fc
[debug]Loading section .init_array, size 0x8 lma 0x8002a04
[debug]Loading section .fini_array, size 0x4 lma 0x8002a0c
[debug]Loading section .data, size 0x464 lma 0x8002a10
[debug]Loading section .jcr, size 0x4 lma 0x8002e74
[debug]Start address 0x80026b9, load size 11896
[debug]Transfer rate: 1 KB/sec, 1189 bytes/write.
[debug]>>>>>>cb_gdb:
[debug]> monitor reset
[debug]Loading section .isr_vector, size 0x188 lma 0x8000000
[debug]Loading section .text, size 0x2874 lma 0x8000188
[debug]Loading section .ARM, size 0x8 lma 0x80029fc
[debug]Loading section .init_array, size 0x8 lma 0x8002a04
[debug]Loading section .fini_array, size 0x4 lma 0x8002a0c
[debug]Loading section .data, size 0x464 lma 0x8002a10
[debug]Loading section .jcr, size 0x4 lma 0x8002e74
[debug]Start address 0x80026b9, load size 11896
[debug]Transfer rate: 1 KB/sec, 1189 bytes/write.
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/andre/Projekte/STM32F4-Test/main.c:13"
[debug]STM32 Successfully completed reset operation
[debug]No source file named C.
[debug]>>>>>>cb_gdb:Breakpoint 1 ("C:/Users/andre/Projekte/STM32F4-Test/main.c:13) pending.

STM32 Successfully completed reset operation
No source file named C.

[debug]> continue
[debug]>>>>>>cb_gdb:
[debug]Program received signal SIGINT, Interrupt.
[debug]0x080011e0 in framebuffer_refresh () at oled\framebuffer.c:105
[debug]C:/Users/andre/Projekte/STM32F4-Test/oled\framebuffer.c:105:2095:beg:0x80011e0
[debug]>>>>>>cb_gdb:

Program received signal SIGINT, Interrupt.
At C:/Users/andre/Projekte/STM32F4-Test/oled\framebuffer.c:105
> break main.c:13

[debug]> break main.c:13
[debug]Breakpoint 2 at 0x80018a2: file main.c, line 13.
[debug]>>>>>>cb_gdb:

Breakpoint 2 at 0x80018a2: file main.c, line 13.

#######################################################################################

when i manually send a command to add the breakpoint with a relative path to the source file everything works as expceted.

another weird thing is that the "load" command gets executed twice (but the command to be sent exists only once..)

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Terry Guo (terry.guo) said : 		#1

Did you try it in Linux environment like Ubuntu? If you can build you project under Ubuntu and set break point, then the issue may be related to Mingw32.

Revision history for this message
andre (andre-wittmann) said : 		#2

I didn't try it in Linux but i guess it wouldn't happen there.

As the error message says:
"No source file named C."
I guess the gdb interpretes the colon at C:/ as the colon you have between the file name and line where to set the Breakpoint
and as there isn't any colon in a usual linux-path the error won't happen there.

Revision history for this message
Terry Guo (terry.guo) said : 		#3

OK. I am installing the latest Code:Blocks 10.05 to see if I can reproduce your issue. Is you project a general C project or project that contain some special things?

Revision history for this message
andre (andre-wittmann) said : 		#4

It's a plain C project, but you don't even need codeblocks to reproduce the problem.

just launch the arm-none-eabi-gdb from cmd,
connect to a gdb server and
try to make a breakpoint - once with a absolute path and once with a relative path and you get the error

like:

break C:/src/main.c:13
(->error)

break main.c:13
(->ok)

Revision history for this message
Terry Guo (terry.guo) said : 		#5

Confirmed.

And seems it is a bug on handling the windows absolute path, especially the colon. There are some discussions on this in GDB mailing list and bugzilla, you can refer to:

http://sourceware.org/ml/gdb/2011-06/msg00074.html
http://sourceware.org/bugzilla/show_bug.cgi?id=12843

I am not sure whether those fixes are in our release. I will check them and then get back to you tomorrow.

Revision history for this message
Terry Guo (terry.guo) said : 		#6

The GDB in our release is based on GDB 7.3.1 which is made prior to those fixes. So we do have this defect. I tried the fix said in the Bugzilla and confirmed it did solved this issue. And after a preliminary evaluation, I don't think it will bring side effect. So I recommend you to try it.

For the twice execution of "load" command, I couldn't reproduce it with or without the above fix. It works fine for me as you can see from my screen paste:

 (gdb) target remote :61234
Remote debugging using :61234
0x0800b9ae in I2C_ClearITPendingBit ()
(gdb) load
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0xef30 lma 0x8000188
Loading section .data, size 0x1a0 lma 0x800f0b8
Start address 0x800ef69, load size 62040
Transfer rate: 3 KB/sec, 2697 bytes/write.
(gdb) b main
Breakpoint 1 at 0x800024e: file main.c, line 77.
(gdb) b D:\cygwin\home\terguo01\stlink\example\stm32f4\Projects\discovery_demo\main.c : 80
Breakpoint 2 at 0x8000262: file main.c, line 80.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at main.c:77
77 STM_EVAL_PBInit(BUTTON_USER, BUTTON_MODE_EXTI);
(gdb) c
Continuing.

Breakpoint 2, main () at main.c:80
80 STM_EVAL_LEDInit(LED3);
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0800024e in main at main.c:77
        breakpoint already hit 1 time
2 breakpoint keep y 0x08000262 in main at main.c:80
        breakpoint already hit 1 time
(gdb)

Is it something specific to Code:Block? Are you using gdb scripts or executing those commands manually? In my standalone gdb, the "load" only gets executed once.

Revision history for this message
andre (andre-wittmann) said : 		#7

Can you provide me your patched binaries to try them? (the main reason i tried this toolchain was not to have to build it all on myself ;) )

The double-execution of 'load' is only within Code::Blocks, not when running the gdb direct from console.

Revision history for this message
Terry Guo (terry.guo) said : 		#8

I can promise you that this issue will be addressed in the next release. But I am sorry that I can't just provide you any patched binaries, because we do have strict plan and process to deliver things. I hope you can understand.

Can you help with this problem?

Provide an answer of your own, or ask andre for more information if necessary.

To post a message you must log in.