Home » Language IDEs » C / C++ IDE (CDT) » GDB Hardware Debugging Breakpoints problem
| GDB Hardware Debugging Breakpoints problem [message #200204] |
Fri, 24 August 2007 11:01  |
Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
In CDT 4.0, with the GDB Hardware Debugging feature, I'm having issues
with breakpoints. If anyone is aware of whether I'm doing something
wrong here I would appreciate knowing, otherwise I'll look at raising
bugs on these.
1) When I set a breakpoint, let's say I do it from the console like
e.g.:
b FuncName
The output in the console (verbose mode) shows that the breakpoint has
been added in the correct file, but the breakpoints view in the CDT
debug perspective shows the breakpoint in the .elf file that I have
set in the "C/C++ Application:" field of the "Main" tab in the debug
configuration.
2) When I set a number of breakpoints in the "Run Commands" field of
the "Startup" tab, I have a number of breakpoints supposedly in my
..elf file which, when I relaunch the program, Eclipse tries to set and
receives errors from gdb as a result.
3) When I right click next to a source line and select "Toggle
breakpoint", the breakpoints view shows two breakpoints at that place
with different icons. One icon is just a dot, one is a dot with a tick
next to it. This doesn't seem right and, additionally, I can't find
anything that explains what these icons mean (Could someone please
point me to a reference - it doesn't seem to be in the help, and
there's another type of icon whch has a dot, a tick, and an arrow
across the top of it!). When I repeat this on the same line, the entry
with only a dot icon is removed, but the other entry is not, meaning
that the breakpoint still exists (and is still shown in the margin
next to the source line). If I do this again I end up with 3 entries
in the Breakpoints view!
4) Finally, not related to breakpoints, but in the debug perspective,
when I open a file using the "File" -> "Open" command on the menus I
get a java Null Pointer Exception.
FWIW, I'm using MIPS development kit with sde-gdb and an Abatron
BDI2000 probe. This is a pristine install of Eclipse Europa with only
the GDB Hardware Debugging feature added.
This all looks really promising but it would be nice if it all made
sense.
Any help gratefully appreciated.
John
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200627 is a reply to message #200204] |
Wed, 29 August 2007 07:32  |
| Eclipse User |
|
|
|
Originally posted by: paul.mcconkey.net
Hi John,
It sounds like the Debug perspective and GDB aren't staying synchronised
with the way you're using them. I haven't come across this issue, but it has
never occurred to me to set breakpoints using the console.
> 1) When I set a breakpoint, let's say I do it from the console like
> e.g.:
>
> b FuncName
>
> The output in the console (verbose mode) shows that the breakpoint has
> been added in the correct file, but the breakpoints view in the CDT
> debug perspective shows the breakpoint in the .elf file that I have
> set in the "C/C++ Application:" field of the "Main" tab in the debug
> configuration.
I don't know what you mean here - I just have the name of the .elf file in
the "C/C++ Application:" field of the "Main" tab, no breakpoint set.
On the Debug tab I have m68k-elf-gdb in the GDB Command field, The Init file
field is empty, command set is Standard (Windows), protocol version MI2,
verbose unchecked (although I do use this occasionally), remote target
unchecked.
Startup tab: Init commands are target remote | m68k-elf-sprite
pe://USBMultilink/ m5282evb to set up my BDM wiggler followed by load. I
used to have break main in here many moons ago but dropped it. Automatically
load image is unchecked - this didn't seem to work very well. Run commands
are just continue.
So you see it is really pretty minimal - I use Eclipse to set
breakpoints/watchpoints, etc. (Not using the console).
> 2) When I set a number of breakpoints in the "Run Commands" field of
> the "Startup" tab, I have a number of breakpoints supposedly in my
> .elf file which, when I relaunch the program, Eclipse tries to set and
> receives errors from gdb as a result.
Could this be related to the Automatically load image? Try putting load,
followed by your breakpoint commands in the init commands script.
> 3) When I right click next to a source line and select "Toggle
> breakpoint", the breakpoints view shows two breakpoints at that place
> with different icons. One icon is just a dot, one is a dot with a tick
> next to it. This doesn't seem right and, additionally, I can't find
> anything that explains what these icons mean (Could someone please
> point me to a reference - it doesn't seem to be in the help, and
> there's another type of icon whch has a dot, a tick, and an arrow
> across the top of it!). When I repeat this on the same line, the entry
> with only a dot icon is removed, but the other entry is not, meaning
> that the breakpoint still exists (and is still shown in the margin
> next to the source line). If I do this again I end up with 3 entries
> in the Breakpoints view!
The CDT icons are a complete mystery to me and the documentation is not
detailed enough/out of date so it's hard to know where to find out. I am a
complete Java novice, but it may be that installing the CDT SDK and looking
at the source may be a way to find out.
> 4) Finally, not related to breakpoints, but in the debug perspective,
> when I open a file using the "File" -> "Open" command on the menus I
> get a java Null Pointer Exception.
What sort of file? You should look at the Eclipse error log to see what
happened.
> FWIW, I'm using MIPS development kit with sde-gdb and an Abatron
> BDI2000 probe. This is a pristine install of Eclipse Europa with only
> the GDB Hardware Debugging feature added.
You could always try the Zylin CDT extensions, which do pretty much the same
job as the Hardware debugging stuff.
> This all looks really promising but it would be nice if it all made
> sense.
As far as I'm concerned Eclipse/CDT is the best development environment that
I have used for embedded work, so it's worth persevering to get a system
that works for you.
Cheers,
Paul.
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200635 is a reply to message #200204] |
Wed, 29 August 2007 08:37 |
| Eclipse User |
|
|
|
Originally posted by: dmsubs.NOSPAM.consertum.com
John,
The first obvious 'mistake' is that you are not meant to set breakpoints
manually (either through the console, or through the Load/Run commands). You are
doing this behind Eclipse's back and so it has no knowledge of what you have
done. Breakpoints should be set through Eclipse.
So that leads to the question - why are you trying to set breakpoints this way?
--
Derek
John McCabe wrote:
> In CDT 4.0, with the GDB Hardware Debugging feature, I'm having issues
> with breakpoints. If anyone is aware of whether I'm doing something
> wrong here I would appreciate knowing, otherwise I'll look at raising
> bugs on these.
>
> 1) When I set a breakpoint, let's say I do it from the console like
> e.g.:
>
> b FuncName
>
> The output in the console (verbose mode) shows that the breakpoint has
> been added in the correct file, but the breakpoints view in the CDT
> debug perspective shows the breakpoint in the .elf file that I have
> set in the "C/C++ Application:" field of the "Main" tab in the debug
> configuration.
>
> 2) When I set a number of breakpoints in the "Run Commands" field of
> the "Startup" tab, I have a number of breakpoints supposedly in my
> .elf file which, when I relaunch the program, Eclipse tries to set and
> receives errors from gdb as a result.
>
> 3) When I right click next to a source line and select "Toggle
> breakpoint", the breakpoints view shows two breakpoints at that place
> with different icons. One icon is just a dot, one is a dot with a tick
> next to it. This doesn't seem right and, additionally, I can't find
> anything that explains what these icons mean (Could someone please
> point me to a reference - it doesn't seem to be in the help, and
> there's another type of icon whch has a dot, a tick, and an arrow
> across the top of it!). When I repeat this on the same line, the entry
> with only a dot icon is removed, but the other entry is not, meaning
> that the breakpoint still exists (and is still shown in the margin
> next to the source line). If I do this again I end up with 3 entries
> in the Breakpoints view!
>
> 4) Finally, not related to breakpoints, but in the debug perspective,
> when I open a file using the "File" -> "Open" command on the menus I
> get a java Null Pointer Exception.
>
> FWIW, I'm using MIPS development kit with sde-gdb and an Abatron
> BDI2000 probe. This is a pristine install of Eclipse Europa with only
> the GDB Hardware Debugging feature added.
>
> This all looks really promising but it would be nice if it all made
> sense.
>
> Any help gratefully appreciated.
> John
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200643 is a reply to message #200627] |
Wed, 29 August 2007 09:09 |
| Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
On Wed, 29 Aug 2007 08:32:43 +0100, "Paul McConkey"
<paul@mcconkey.net> wrote:
>Hi John,
>
>It sounds like the Debug perspective and GDB aren't staying synchronised
>with the way you're using them. I haven't come across this issue, but it has
>never occurred to me to set breakpoints using the console.
I just tried it to see what happened :-)
>> 1) When I set a breakpoint, let's say I do it from the console like
>> e.g.:
>>
>> b FuncName
>>
>> The output in the console (verbose mode) shows that the breakpoint has
>> been added in the correct file, but the breakpoints view in the CDT
>> debug perspective shows the breakpoint in the .elf file that I have
>> set in the "C/C++ Application:" field of the "Main" tab in the debug
>> configuration.
>I don't know what you mean here - I just have the name of the .elf file in
>the "C/C++ Application:" field of the "Main" tab, no breakpoint set.
Ah - you've misinterpreted what I said but, reading that again, it's
quite easy to see why! I just have the name of the .elf file in the
"C/C++ Application:" field of the "Main" tab; setting the breakpoint
is done later. However when I set a breakpoint either from the console
or in the "Run Commands" box of the debug configuration, the
breakpoints view shows that the breakpoint is set in the .elf file, it
doesn't show the source file name.
>On the Debug tab I have m68k-elf-gdb in the GDB Command field, The Init file
>field is empty, command set is Standard (Windows), protocol version MI2,
>verbose unchecked (although I do use this occasionally), remote target
>unchecked.
Interesting. I haven't tried changing the protocol versions.
>Startup tab: Init commands are target remote | m68k-elf-sprite
>pe://USBMultilink/ m5282evb to set up my BDM wiggler followed by load. I
>used to have break main in here many moons ago but dropped it. Automatically
>load image is unchecked - this didn't seem to work very well. Run commands
>are just continue.
>So you see it is really pretty minimal - I use Eclipse to set
>breakpoints/watchpoints, etc. (Not using the console).
That's another issue as I mentioned later :-)
>> 2) When I set a number of breakpoints in the "Run Commands" field of
>> the "Startup" tab, I have a number of breakpoints supposedly in my
>> .elf file which, when I relaunch the program, Eclipse tries to set and
>> receives errors from gdb as a result.
>Could this be related to the Automatically load image? Try putting load,
>followed by your breakpoint commands in the init commands script.
I don't use Automatically load image, but your suggestion about moving
the breakpoint settings to the Initialization box is worth trying.
>> 3) When I right click next to a source line and select "Toggle
>> breakpoint", the breakpoints view shows two breakpoints at that place
>> with different icons. One icon is just a dot, one is a dot with a tick
>> next to it. This doesn't seem right and, additionally, I can't find
>> anything that explains what these icons mean (Could someone please
>> point me to a reference - it doesn't seem to be in the help, and
>> there's another type of icon whch has a dot, a tick, and an arrow
>> across the top of it!). When I repeat this on the same line, the entry
>> with only a dot icon is removed, but the other entry is not, meaning
>> that the breakpoint still exists (and is still shown in the margin
>> next to the source line). If I do this again I end up with 3 entries
>> in the Breakpoints view!
>The CDT icons are a complete mystery to me and the documentation is not
>detailed enough/out of date so it's hard to know where to find out. I am a
>complete Java novice, but it may be that installing the CDT SDK and looking
>at the source may be a way to find out.
That may be worthwhile if no one else knows what they mean! I'm
concerned about the creation of two breakpoints though, and only
removing one of them when I toggle etc.
>> 4) Finally, not related to breakpoints, but in the debug perspective,
>> when I open a file using the "File" -> "Open" command on the menus I
>> get a java Null Pointer Exception.
>What sort of file? You should look at the Eclipse error log to see what
>happened.
A C++ file. I'll try it again some time today and have a look at the
error log.
>> FWIW, I'm using MIPS development kit with sde-gdb and an Abatron
>> BDI2000 probe. This is a pristine install of Eclipse Europa with only
>> the GDB Hardware Debugging feature added.
>You could always try the Zylin CDT extensions, which do pretty much the same
>job as the Hardware debugging stuff.
Yes - I may go down that route. At least I know that's been around for
a while and there appears to be more documentation about it than the
official CDT one.
>> This all looks really promising but it would be nice if it all made
>> sense.
>As far as I'm concerned Eclipse/CDT is the best development environment that
>I have used for embedded work, so it's worth persevering to get a system
>that works for you.
Thanks. I hope so. I would love to be able to use Eclipse in this way.
John
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200651 is a reply to message #200635] |
Wed, 29 August 2007 09:12 |
| Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
On Wed, 29 Aug 2007 09:37:04 +0100, Derek Morris
<dmsubs@NOSPAM.consertum.com> wrote:
>John,
>
>The first obvious 'mistake' is that you are not meant to set breakpoints
>manually (either through the console, or through the Load/Run commands). You are
>doing this behind Eclipse's back and so it has no knowledge of what you have
>done. Breakpoints should be set through Eclipse.
>
>So that leads to the question - why are you trying to set breakpoints this way?
Automation essentially (convenience - I always want to set those
breakpoints - at least, for the moment), and possibly ignorance - does
Eclipse automatically set an initial breakpoint at the start of the
program? I want to make sure that, when I press the Debug button, it's
going to stop at the place I want it to.
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200667 is a reply to message #200651] |
Wed, 29 August 2007 09:28 |
| Eclipse User |
|
|
|
Originally posted by: dmsubs.NOSPAM.consertum.com
By default, Eclipse sets a breakpoint on main() (setting is on the Debugger
tab). It also remembers breakpoints between runs, so no need to remember where
you set them - it does it for you. If you right click on a breakpoint icon (blue
dot on the left) it can show you a breakpoint dialog that shows its properties.
You can also see what breakpoints are set in the Breakpoints view.
HTH
--
Derek
John McCabe wrote:
> On Wed, 29 Aug 2007 09:37:04 +0100, Derek Morris
> <dmsubs@NOSPAM.consertum.com> wrote:
>
>> John,
>>
>> The first obvious 'mistake' is that you are not meant to set breakpoints
>> manually (either through the console, or through the Load/Run commands). You are
>> doing this behind Eclipse's back and so it has no knowledge of what you have
>> done. Breakpoints should be set through Eclipse.
>>
>> So that leads to the question - why are you trying to set breakpoints this way?
>
> Automation essentially (convenience - I always want to set those
> breakpoints - at least, for the moment), and possibly ignorance - does
> Eclipse automatically set an initial breakpoint at the start of the
> program? I want to make sure that, when I press the Debug button, it's
> going to stop at the place I want it to.
>
>
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200675 is a reply to message #200667] |
Wed, 29 August 2007 10:08 |
| Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
On Wed, 29 Aug 2007 10:28:14 +0100, Derek Morris
<dmsubs@NOSPAM.consertum.com> wrote:
>By default, Eclipse sets a breakpoint on main() (setting is on the Debugger
>tab).
This setting isn't in the GDB Hardware Debugging configuration's
Debugger tab.
>It also remembers breakpoints between runs, so no need to remember where
>you set them - it does it for you. If you right click on a breakpoint icon (blue
>dot on the left) it can show you a breakpoint dialog that shows its properties.
>You can also see what breakpoints are set in the Breakpoints view.
Thanks. It's worth re-reading my original message though wrt setting
breakpoints and viewing them in the breakpoints view.
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200684 is a reply to message #200643] |
Wed, 29 August 2007 10:25 |
| Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
On Wed, 29 Aug 2007 10:09:55 +0100, John McCabe
<john@nospam.assen.demon.co.uk> wrote:
>On Wed, 29 Aug 2007 08:32:43 +0100, "Paul McConkey"
><paul@mcconkey.net> wrote:
>
>>> 2) When I set a number of breakpoints in the "Run Commands" field of
>>> the "Startup" tab, I have a number of breakpoints supposedly in my
>>> .elf file which, when I relaunch the program, Eclipse tries to set and
>>> receives errors from gdb as a result.
>>Could this be related to the Automatically load image? Try putting load,
>>followed by your breakpoint commands in the init commands script.
>I don't use Automatically load image, but your suggestion about moving
>the breakpoint settings to the Initialization box is worth trying.
Putting the breakpoint commands in the Initialization section results
in Eclipse not listing any of them in the Breakpoints view.
>>> 4) Finally, not related to breakpoints, but in the debug perspective,
>>> when I open a file using the "File" -> "Open" command on the menus I
>>> get a java Null Pointer Exception.
>
>>What sort of file? You should look at the Eclipse error log to see what
>>happened.
>
>A C++ file. I'll try it again some time today and have a look at the
>error log.
Tried that again. The error log reports a load of problems! It has a
list of:
1) Unhandled event loop exception (4 of these; two at 11:21:36.671 and
two at 11:21:36.686 from the org.eclipse.ui plug-in)
2) An unexpected exception was thrown. (from the
org.eclipse.ui.workbench plug-in)
3) Problems occurred when invoking code from plug-in
"org.eclipse.ui.workbench".
The details of #3 (presumably the root cause of the problem) are:
java.lang.NullPointerException
at org.eclipse.core.runtime.Path.<init>(Path.java:152)
at org.eclipse.core.runtime.Path.isValidPath(Path.java:673)
at
org.eclipse.cdt.debug.internal.ui.actions.ResumeAtLineAdapte r.convertPath(ResumeAtLineAdapter.java:211)
at
org.eclipse.cdt.debug.internal.ui.actions.ResumeAtLineAdapte r.canResumeAtLine(ResumeAtLineAdapter.java:167)
at
org.eclipse.cdt.debug.internal.ui.actions.RetargetResumeAtLi neAction.canPerformAction(RetargetResumeAtLineAction.java:86 )
at
org.eclipse.cdt.debug.internal.ui.actions.RetargetAction.upd ate(RetargetAction.java:212)
at
org.eclipse.cdt.debug.internal.ui.actions.RetargetAction.par tActivated(RetargetAction.java:148)
at
org.eclipse.ui.internal.PartListenerList$1.run(PartListenerL ist.java:72)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:857)
at
org.eclipse.ui.internal.PartListenerList.fireEvent(PartListe nerList.java:57)
at
org.eclipse.ui.internal.PartListenerList.firePartActivated(P artListenerList.java:70)
at
org.eclipse.ui.internal.PartService.firePartActivated(PartSe rvice.java:73)
at
org.eclipse.ui.internal.PartService.setActivePart(PartServic e.java:171)
at
org.eclipse.ui.internal.WWinPartService.updateActivePart(WWi nPartService.java:124)
at
org.eclipse.ui.internal.WWinPartService.access$0(WWinPartSer vice.java:115)
at
org.eclipse.ui.internal.WWinPartService$1.partDeactivated(WW inPartService.java:48)
at
org.eclipse.ui.internal.PartListenerList2$4.run(PartListener List2.java:113)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:857)
at
org.eclipse.ui.internal.PartListenerList2.fireEvent(PartList enerList2.java:53)
at
org.eclipse.ui.internal.PartListenerList2.firePartDeactivate d(PartListenerList2.java:111)
at
org.eclipse.ui.internal.PartService.firePartDeactivated(Part Service.java:116)
at
org.eclipse.ui.internal.PartService.setActivePart(PartServic e.java:165)
at
org.eclipse.ui.internal.WorkbenchPagePartList.fireActivePart Changed(WorkbenchPagePartList.java:56)
at
org.eclipse.ui.internal.PartList.setActivePart(PartList.java :126)
at
org.eclipse.ui.internal.WorkbenchPage.setActivePart(Workbenc hPage.java:3384)
at
org.eclipse.ui.internal.WorkbenchPage.activate(WorkbenchPage .java:602)
at
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched( WorkbenchPage.java:2730)
at
org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(Workben chPage.java:2633)
at
org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPag e.java:2625)
at
org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.j ava:2577)
at
org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
at
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2572)
at
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2556)
at
org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPa ge.java:2539)
at org.eclipse.ui.ide.IDE.openEditorOnFileStore(IDE.java:1090)
at
org.eclipse.ui.internal.ide.actions.OpenLocalFileAction.run( OpenLocalFileAction.java:105)
at
org.eclipse.ui.internal.ide.actions.OpenLocalFileAction.run( OpenLocalFileAction.java:75)
at
org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:256)
at
org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPl uginAction.java:229)
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:545)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:490)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:402)
at
org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
at
org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3682)
at
org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3293)
at
org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
at
org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
at
org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 19)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:461)
at
org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:153)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:363)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 504)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
|
|
|
| Re: GDB Hardware Debugging Breakpoints problem [message #200692 is a reply to message #200635] |
Wed, 29 August 2007 10:37 |
| Eclipse User |
|
|
|
Originally posted by: john.nospam.assen.demon.co.uk
On Wed, 29 Aug 2007 09:37:04 +0100, Derek Morris
<dmsubs@NOSPAM.consertum.com> wrote:
>John,
>
>The first obvious 'mistake' is that you are not meant to set breakpoints
>manually (either through the console, or through the Load/Run commands). You are
>doing this behind Eclipse's back and so it has no knowledge of what you have
>done. Breakpoints should be set through Eclipse.
>
>So that leads to the question - why are you trying to set breakpoints this way?
Also - I can't see how to set breakpoints on a named function from
Eclipse, this is something you can do in the console.
E.g. if I want to set a breakpoint on function XYZ (let's say it's a
static function for example) then I can use
b XYZ
in the console (or in the startup commands) whereas, if I waited until
I was in Eclipse, I would need to find the file that it is in, open
it, then set [two] breakpoint[s!] on that line. (or would I, if you
know how to set a breakpoint in a function from Eclipse in the GDB
Hardware Debugging feature please let me know).
*Note the "[two] breakpoint[s!]" bit refers to the issue I'm having
with two breakpoints being set when I "Toggle Breakpoint" from the
editor.
|
|
| |
Goto Forum:
Current Time: Fri Oct 18 01:51:02 GMT 2024
Powered by FUDForum. Page generated in 0.04482 seconds |
] 
Search
Help
Register
Login
Home
