Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 06:20 Go to next message
tony burton is currently offline 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 #836411 is a reply to message #836299] Wed, 04 April 2012 09:03 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
Using breakpoints with GDB has changed a lot in Indigo. Look in the 'gdb traces' to see what is happening between CDT and GDB:
http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27gdb_traces.27.2C_where_can_I_find_them.3F

Marc
Re: indigo cdt breakpoint problem [message #836432 is a reply to message #836411] Wed, 04 April 2012 09:39 Go to previous messageGo to next message
tony burton is currently offline 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 #836437 is a reply to message #836432] Wed, 04 April 2012 09:42 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
The tick will only appear once GDB has been told to set the breakpoint and has succeeded in setting it. It seems that this does not happen for you in Indigo.

In your Indigo gdb traces, do you see _any_ -break-insert commands sent to GDB?

What GDB version are you using?
Re: indigo cdt breakpoint problem [message #836462 is a reply to message #836437] Wed, 04 April 2012 10:05 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
No, when I set the breakpoint, I don't see any -break-insert commands sent to GDB (in Indigo).

my gdb version is:

$ arm-none-eabi-gdb -v
GNU gdb (Sourcery G++ Lite 2010.09-51) 7.2.50.20100908-cvs

I notice that, in Helios, when a breakpoint is already set and the debugger has not been launched, the blue dot has no tick. When the debugger is launched, the tick appears straight away, before the program is loaded. Note that I've written a plugin that adds a new launcher to the debug configuration and this plugin loads the program.
Re: indigo cdt breakpoint problem [message #836598 is a reply to message #836462] Wed, 04 April 2012 13:24 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
> I notice that, in Helios, when a breakpoint is already set and the debugger has not been launched,
> the blue dot has no tick. When the debugger is launched, the tick appears straight away, before
> the program is loaded. Note that I've written a plugin that adds a new launcher to the debug
> configuration and this plugin loads the program.

With Indigo, we set breakpoints after the program is specified to GDB. This is to allow supporting
multi-process debugging.

Maybe your plugin is conflicting with that new behavior.

marc
Re: indigo cdt breakpoint problem [message #837259 is a reply to message #836598] Thu, 05 April 2012 08:59 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
Hi Marc,
I think I understand the problem: as I am loading the application within my plugin, Eclipse doesn't know it has been loaded. There are 2 possible solutions I can think of, but I don't know how to realize them;
1) Inform Eclipse that the program has been loaded
2) add the startup tab from the hardware debugging launcher to my launcher

I think the second solution would be the best. What is the class that creates the startup tab called? If I could add this tab to my launch configuration tab group maybe my problems would be over,

Thanks,

Antony
Re: indigo cdt breakpoint problem [message #837261 is a reply to message #837259] Thu, 05 April 2012 09:03 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
The startup tab is:

org.eclipse.cdt.debug.gdbjtag.ui.GDBJtagStartupTab
Re: indigo cdt breakpoint problem [message #837282 is a reply to message #837261] Thu, 05 April 2012 09:27 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
Thanks for that quick reply! I added the startup tab to my launcher configuration, set the application to be loaded, but nothing happens. Is there something else I must do to make the configuration details in the startup tab be used?
Re: indigo cdt breakpoint problem [message #837350 is a reply to message #837282] Thu, 05 April 2012 11:11 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
The binary specified in the startup tab will only be used when you use a Hardware launch. If you are using a different launch, it won't be used.

I suggest you look at the code path that your launch is following to see why things are not working. For a local, remote or post-mortem launch (but not a hardware or attach launch) you should expect

FinalLaunchSequence.stepNewProcess() to call IProcesses.debugNewProcess, which will end up in DebugNewProcessSequence.stepSetExecutable() and DebugNewProcessSequence.stepStartTrackingBreakpoints().

For an attach launch, IGDBProcesses.attachDebuggerToProcess() will take care of setting breakpoints.

Marc

P.S. I'm looking at the latest code base, be I don't believe much has changed with respect to that code path.
Re: indigo cdt breakpoint problem [message #837361 is a reply to message #837350] Thu, 05 April 2012 11:24 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
Yes, we are not using jtag, we are remotely debugging. Does that mean that I can't use the startup tab and must manage the download with my plugin as I did before and than call IGDBProcesses.attachDebuggerToProcess()? If so, could you please show me how?
Re: indigo cdt breakpoint problem [message #837366 is a reply to message #837361] Thu, 05 April 2012 11:33 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
Can't you use the "C/C++ Remote Application" launch? If you install RSE, it has an option to upload the binary to your target automatically.
http://wiki.eclipse.org/CDT/User/FAQ#How_do_I_debug_a_remote_application.3F

Marc
Re: indigo cdt breakpoint problem [message #837375 is a reply to message #837366] Thu, 05 April 2012 11:39 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
No, because I have written a plugin that does other things which depend on initialisations etc. done during the launch...
Re: indigo cdt breakpoint problem [message #837379 is a reply to message #837375] Thu, 05 April 2012 11:46 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
> Yes, we are not using jtag, we are remotely debugging. Does that mean that I can't use the startup tab
> and must manage the download with my plugin as I did before and than call IGDBProcesses.attachDebuggerToProcess()?

You don't have to use 'attach' if that is not what you want. You will need to figure out how your plugin needs to
play with CDT, to properly fill the launch attributes that CDT looks for when launching. If the actual sequence
of operations of the launch (FinalLaunchSequence, DebugNewProcessSequence) are not the steps that you need, then
you will need extend them to skip/add the steps you need.

The best way is to look at how those classes are used in CDT.

Marc


Re: indigo cdt breakpoint problem [message #837384 is a reply to message #837379] Thu, 05 April 2012 11:55 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
OK, thanks, but is there not an easy way to inform eclipse that I have loaded the application and that beakpoints can be used as with Helios?
Re: indigo cdt breakpoint problem [message #837424 is a reply to message #837384] Thu, 05 April 2012 12:46 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
It is hard for me to know, since I don't know your plugin.
Hopefully by getting a little more familiar with the code, you can find a nice way to do it.

Marc
Re: indigo cdt breakpoint problem [message #838095 is a reply to message #837424] Fri, 06 April 2012 10:59 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
OK, I'll try and follow the code as you suggest to see what's happening. Are there any docs which explain the new way of functionning?

Thanks again,

Antony
Re: indigo cdt breakpoint problem [message #839971 is a reply to message #838095] Mon, 09 April 2012 09:46 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
Sorry, no docs beyond javadoc.

Marc
Re: indigo cdt breakpoint problem [message #856247 is a reply to message #837424] Wed, 25 April 2012 09:55 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
Hi Marc,
Have been busy on other work and have come back this week to Eclipse and I've found the solution to my problem - in my launcher's debug tab, I was extending AttachCDebuggerTab instead of CDebuggerTab. Anyway all is working fine anew!
There is one problem though: gdb sends a qThreadExtraInfo command for each thread and we return a string indicating the thread's state (running, suspended, waiting etc.).
In Helios, this information was displayed in the debug view. I can't remember exactly where but something like this:

Thread [9] WAITING (Running)

(WAITING is the qThreadExtraInfo we return for the given thread)

Now, in Indigo, this info is no longer displayed.

Is this a bug or must we do something so that it is displayed?

Thanks,

Antony
Re: indigo cdt breakpoint problem [message #856563 is a reply to message #856247] Wed, 25 April 2012 15:44 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
I'm not sure what when the qThreadExtraInfo is used. How does it translate to an MI command?
We use -thread-info to request thread info from GDB and display some of it in the Debug view.
It is possible that we no longer display as much info as we used to... although I would be surprised.
Are you sure you use to see it?

Marc

Re: indigo cdt breakpoint problem [message #857117 is a reply to message #856563] Thu, 26 April 2012 04:58 Go to previous messageGo to next message
tony burton is currently offline 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 #867785 is a reply to message #857117] Tue, 01 May 2012 09:30 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
Registered: July 2009
Senior Member
Thanks for not giving up. You found a bug.
I fixed it and it will be part of the next CDT release in June.
https://bugs.eclipse.org/378152

> 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

This should not happen. Looking at the GDB traces you posted above, I see 8 calls to -thread-info,
but they are for 8 different threads. Are you seeing something different in wireshark? Why would it not be
in the gdb traces?

Thanks

Marc
Re: indigo cdt breakpoint problem [message #868622 is a reply to message #867785] Wed, 02 May 2012 05:57 Go to previous messageGo to next message
tony burton is currently offline 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 94 times)
Re: indigo cdt breakpoint problem [message #868760 is a reply to message #868622] Wed, 02 May 2012 09:57 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
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 #868856 is a reply to message #868760] Wed, 02 May 2012 12:30 Go to previous messageGo to next message
tony burton is currently offline tony burton
Messages: 26
Registered: April 2012
Location: France
Junior Member
Thanks for the info on how to get the fix - I'll try it tomorrow. I think we need > GDB 7.0 for non-stop mode.

Yes I see that the GDB traces show only one answer per thread, so maybe the problem is elsewhere, in any case if you open the html file in a browser, you'll see the communications between GDB and the gdbserver with requests coming from gdb and answers sent back by the target:
1) First the T command (is thread alive) for each thread (T1, T2 etc.)
2) The qfThreadInfo command
3) qThreadExtraInfo command for each thread

then 1) and 2) are repeated 3 times
then 3) is repeated

and all this is repeated another 7 times!

I have another couple of questions:

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.
2) The option "Force thread list on suspend" doesn't seem to change anything - what should it do?

Thanks again,

Tony
Re: indigo cdt breakpoint problem [message #868885 is a reply to message #868856] Wed, 02 May 2012 13:22 Go to previous messageGo to next message
Marc Khouzam is currently offline Marc Khouzam
Messages: 274
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 04:59 Go to previous message
tony burton is currently offline 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
Previous Topic:Warning on the problems view does not get cleaned - no .markers file exists
Next Topic:Unresolved includes (not standard include)
Goto Forum:
  


Current Time: Thu Aug 28 07:19:15 EDT 2014

Powered by FUDForum. Page generated in 0.02768 seconds