Home » Language IDEs » C / C++ IDE (CDT) » indigo cdt breakpoint problem(Problem installing breakpoints in indigo cdt)
| indigo cdt breakpoint problem [message #836299] |
Wed, 04 April 2012 10:20  |
 tony burton
Messages: 26
Registered: April 2012
Location: France |
Junior Member |
|
|
Hi,
We have a project (written in C and using the CDT and DSF debugging frameworks) which worked well under Helios, but now, with Indigo, there is a problem with breakpoints. Under Indigo, when a breakpoint is set or removed, the information is not sent to the target via gdb. Also, the little blue icon appears in the left hand ruler, but there is no tick.
Has anybody any ideas please?
Thanks in advance,
Antony
|
|
| |
| Re: indigo cdt breakpoint problem [message #836432 is a reply to message #836411] |
Wed, 04 April 2012 13:39  |
tony burton
Messages: 26
Registered: April 2012
Location: France |
Junior Member |
|
|
Hi Marc,
Thanks for the reply. I looked at the traces and, with indigo, when I set a breakpoint a few lines ahead, nothing is sent to gdb and when I resume execution, the program does not stop at the breakpoint and the following appears in the traces:
587,093 94-exec-continue --thread 1
587,093 94^running
587,093 *running,thread-id="1"
587,093 (gdb)
With Helios, when I set the breakpoint, the following appears:
161,156 91-break-insert main.c:324
161,171 91^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x08019d0e",func="m\
ain",file="../SRC/main.c",fullname="c:\\sourceaim\\runtime-eclipseapplication\\stm32demoapplication\\
\src\\main.c",line="324",times="0",original-location="main.c:324"}
161,171 (gdb)
...and when I resume execution:
584,421 99^done,depth="1"
584,421 (gdb)
584,421 100-thread-info 1
584,437 100^done,threads=[{id="1",target-id="Thread 1",details="BREAKPOINT ",frame={level="0",addr\
="0x08019d0e",func="main",args=[],file="../SRC/main.c",fullname="c:\\sourceaim\\runtime-eclipseappli\
cation\\stm32demoapplication\\src\\main.c",line="324"},state="stopped"}]
584,437 (gdb)
also, in Helios, once the program is loaded, a tick appears on the blue dot in the left ruler when a breakpoint is applied, in Indigo, there is no tick.
Antony
|
|
| | | | | | | | | | | | | | | | | |
| Re: indigo cdt breakpoint problem [message #857117 is a reply to message #856563] |
Thu, 26 April 2012 08:58 |
tony burton
Messages: 26
Registered: April 2012
Location: France |
Junior Member |
|
|
Hi,
Yes I'm sure I saw it in Helios - we thought it was pretty neat.
Here is the GDB trace after doing a refresh in debug with an application with 8 threads running in the target:
584,125 133-thread-info
584,125 134-list-thread-groups
584,140 133^done,threads=[{id="8",target-id="Thread 9",details="WAITEVENT ",state="running"},{id=\
"7",target-id="Thread 8",details="WAITEVENT ",state="running"},{id="6",target-id="Thread 7",detai\
ls="TWAIT ",state="running"},{id="5",target-id="Thread 5",details="PREEMPTED ",state="runn\
ing"},{id="4",target-id="Thread 4",details="PREEMPTED ",state="running"},{id="3",target-id="Threa\
d 3",details="RUNNING ",state="running"},{id="2",target-id="Thread 2",details="PREEMPTED ",s\
tate="running"},{id="1",target-id="Thread 1",details="PREEMPTED ",state="running"}],current-threa\
d-id="1"
584,140 (gdb)
584,140 134^done,groups=[{id="i1",type="process",pid="42000",executable="c:\\sourceaim\\io32\\eclips\
e\\runtime-eclipseapplication\\f1_urts_dbg_appli\\debug_flash\\F1_URTS_DBG_APPLI"}]
584,140 (gdb)
584,140 135-list-thread-groups
584,140 136-list-thread-groups i1
584,156 135^done,groups=[{id="i1",type="process",pid="42000",executable="c:\\sourceaim\\io32\\eclips\
e\\runtime-eclipseapplication\\f1_urts_dbg_appli\\debug_flash\\F1_URTS_DBG_APPLI"}]
584,156 (gdb)
584,156 136^done,threads=[{id="8",target-id="Thread 9",details="WAITEVENT ",state="running"},{id=\
"7",target-id="Thread 8",details="WAITEVENT ",state="running"},{id="6",target-id="Thread 7",detai\
ls="TWAIT ",state="running"},{id="5",target-id="Thread 5",details="PREEMPTED ",state="runn\
ing"},{id="4",target-id="Thread 4",details="PREEMPTED ",state="running"},{id="3",target-id="Threa\
d 3",details="RUNNING ",state="running"},{id="2",target-id="Thread 2",details="PREEMPTED ",s\
tate="running"},{id="1",target-id="Thread 1",details="PREEMPTED ",state="running"}]
584,156 (gdb)
584,156 137-thread-info 8
584,156 138-thread-info 7
584,156 139-thread-info 6
584,156 140-thread-info 5
584,156 141-thread-info 4
584,171 142-thread-info 3
584,171 143-thread-info 2
584,171 144-thread-info 1
584,171 137^done,threads=[{id="8",target-id="Thread 9",details="WAITEVENT ",state="running"}]
584,171 (gdb)
584,171 138^done,threads=[{id="7",target-id="Thread 8",details="WAITEVENT ",state="running"}]
584,171 (gdb)
584,171 139^done,threads=[{id="6",target-id="Thread 7",details="TWAIT ",state="running"}]
584,171 (gdb)
584,171 140^done,threads=[{id="5",target-id="Thread 5",details="PREEMPTED ",state="running"}]
584,171 (gdb)
584,187 141^done,threads=[{id="4",target-id="Thread 4",details="RUNNING ",state="running"}]
584,187 (gdb)
584,187 142^done,threads=[{id="3",target-id="Thread 3",details="PSEMAPHOR ",state="running"}]
584,187 (gdb)
584,203 143^done,threads=[{id="2",target-id="Thread 2",details="TWAIT ",state="running"}]
584,203 (gdb)
584,203 144^done,threads=[{id="1",target-id="Thread 1",details="PREEMPTED ",state="running"}]
584,203 (gdb)
So it looks like the MI commands used are -thread-info and -list-thread-groups
Here is the gdb console output when executing the info threads command in eclipse debug (this is what used to be displayed in the debug view in Helios):
info threads
8 Thread 9 (WAITEVENT ) (running)
7 Thread 8 (WAITEVENT ) (running)
6 Thread 7 (TWAIT ) (running)
5 Thread 5 (PREEMPTED ) (running)
4 Thread 4 (PREEMPTED ) (running)
3 Thread 3 (PSEMAPHOR ) (running)
2 Thread 2 (RUNNING ) (running)
* 1 Thread 1 (PREEMPTED ) (running)
...and the resulting gdb trace...
055,828 114-interpreter-exec console "info threads"
056,187 ~" 8 Thread 9 (WAITEVENT ) (running)\n"
056,187 ~" 7 Thread 8 (WAITEVENT ) (running)\n"
056,187 ~" 6 Thread 7 (TWAIT ) (running)\n"
056,187 ~" 5 Thread 5 (PREEMPTED ) (running)\n"
056,187 ~" 4 Thread 4 (PREEMPTED ) (running)\n"
056,187 ~" 3 Thread 3 (PSEMAPHOR ) (running)\n"
056,187 ~" 2 Thread 2 (RUNNING ) (running)\n"
056,187 ~"* 1 Thread 1 (PREEMPTED ) (running)\n"
056,187 114^done
056,187 (gdb)
I noticed also, using Wireshark (a network analyzer) that when the refresh command is executed in debug that the info-thread command is sent 8 times for each thread which although does not cause any errors, is superfluous and time consuming for nothing - so maybe the code could be optimized. (But it's just an observation - I do realize that you're really busy!)
Thanks,
Antony
|
|
| |
| Re: indigo cdt breakpoint problem [message #868622 is a reply to message #867785] |
Wed, 02 May 2012 09:57 |
tony burton
Messages: 26
Registered: April 2012
Location: France |
Junior Member |
|
|
Hi Marc,
Thanks for that - is it possible for me to update my CDT installation in Eclipse to reflect the changes in the GDBProcesses file? (BTW, I'm using GDB version 7.2).
As for the -thread-info command I am enclosing a file (html) showing the trace of what happens when we do a refresh in the debug view. I am working using the serial line for communication at the moment, but it is the same using ethernet.
It seems that the command -thread-info, when a thread is specified, returns the info for all the threads, so when this command is executed for each thread it outputs too much data. Maybe it's a bug with GDB, because here is what is written the docs:
The -thread-info Command
Synopsis
-thread-info [ thread-id ]
Reports information about either a specific thread, if the thread-id parameter is present, or about all threads. When printing information about all threads, also reports the current thread.
gdb Command
The `info thread' command prints the same information about all threads.
...and it doesn't seem to matter if you specify the thread or not.
Antony
Attachment: trace.htm
(Size: 75.13KB, Downloaded 706 times)
|
|
|
| Re: indigo cdt breakpoint problem [message #868760 is a reply to message #868622] |
Wed, 02 May 2012 13:57 |
Marc Khouzam
Messages: 357
Registered: July 2009 |
Senior Member |
|
|
Hi Tony,
Getting this new fix is possible but you'll need to install a pre-release of Eclipse and one of CDT.
Another option is to use GDB 7.0 which will display as you expect.
If you do want to get the pre-release of eclipse, you can get Eclipse 3.8 from:
http://download.eclipse.org/eclipse/downloads/eclipse3x.html
or eclipse 4.2 (what the next release will actually use) from:
http://download.eclipse.org/eclipse/downloads/
You can use either one.
Then you can use the CDT that was built at:
https://hudson.eclipse.org/hudson/job/cdt-nightly/1069/
About -thread-info. I'm not sure how to read the html file, but looking at the traces you pasted earlier in this conversation, it seems that -thread-info reports for a single thread at a time:
584,156 137-thread-info 8
584,156 138-thread-info 7
584,156 139-thread-info 6
584,156 140-thread-info 5
584,156 141-thread-info 4
584,171 142-thread-info 3
584,171 143-thread-info 2
584,171 144-thread-info 1
584,171 137^done,threads=[{id="8",target-id="Thread 9",details="WAITEVENT ",state="running"}]
584,171 (gdb)
584,171 138^done,threads=[{id="7",target-id="Thread 8",details="WAITEVENT ",state="running"}]
584,171 (gdb)
584,171 139^done,threads=[{id="6",target-id="Thread 7",details="TWAIT ",state="running"}]
584,171 (gdb)
584,171 140^done,threads=[{id="5",target-id="Thread 5",details="PREEMPTED ",state="running"}]
584,171 (gdb)
584,187 141^done,threads=[{id="4",target-id="Thread 4",details="RUNNING ",state="running"}]
584,187 (gdb)
584,187 142^done,threads=[{id="3",target-id="Thread 3",details="PSEMAPHOR ",state="running"}]
584,187 (gdb)
584,203 143^done,threads=[{id="2",target-id="Thread 2",details="TWAIT ",state="running"}]
584,203 (gdb)
584,203 144^done,threads=[{id="1",target-id="Thread 1",details="PREEMPTED ",state="running"}] |
|
| |
| Re: indigo cdt breakpoint problem [message #868885 is a reply to message #868856] |
Wed, 02 May 2012 17:22 |
Marc Khouzam
Messages: 357
Registered: July 2009 |
Senior Member |
|
|
> ... you'll see the communications between GDB and the gdbserver with requests coming
> from gdb and answers sent back by the target:
This is GDB communication and not in the control of CDT. It is possible that GDB/gdbserver
is not efficient. This is something that should be reported to the GDB community. However,
I suggest trying it with gdb.7.4.1 to see if this has been fixed already. Even better if
you can try it with the development branch of GDB.
> 1) Why, when we step in C, does GDB execute assembler step commands instead of stepping 1
> line of C code? This is also very time consuming and if I step too fast I can make Eclipse
> timeout with the gdbserver.
That's another question for the GDB folks.
2) The option "Force thread list on suspend" doesn't seem to change anything - what should it do?
With gdbserver, when a new thread is created, GDB does not know about it until CDT requests some
thread information. The way CDT is coded, it does its best to be efficient and does not ask for
thread information unless it knows that that info has changed since the last time it asked.
So, we never find out about new threads. When you choose the "Force thread list on suspend",
CDT will ask for thread information to make sure it knows about all the new threads, which will
force GDB to get the latest info from gdbserver.
Marc
|
|
|
| Re: indigo cdt breakpoint problem [message #869342 is a reply to message #868885] |
Thu, 03 May 2012 08:59 |
tony burton
Messages: 26
Registered: April 2012
Location: France |
Junior Member |
|
|
OK, thanks, things are clearer now. I will get GDB 7.4 and try it. However, I looked again at the gdb trace when we do a refresh in the debug view and it does seem that CDT executes several times the same instructions:
(these are the MI commands without answers)
407,718 194-thread-info
407,734 195-list-thread-groups
407,812 196-list-thread-groups
407,812 197-list-thread-groups i1
407,921 198-thread-info 8
407,921 199-thread-info 7
407,921 200-thread-info 6
407,921 201-thread-info 5
407,921 202-thread-info 4
407,921 203-thread-info 3
407,953 205-thread-info 2
407,984 206-thread-info 1
For the other point I see that CDT executes either a step or next command so it's definitely GDB which is doing the assembler steps - why it doesn't set a breakpoint after the current intruction, resume, then when the breakpoint is reached, remove it? I will enquire with the GDB community.
Tony
|
|
|
Goto Forum:
Current Time: Tue Apr 16 12:44:54 GMT 2024
Powered by FUDForum. Page generated in 0.38658 seconds |
] 
Search
Help
Register
Login
Home
