[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Debugging 2 programs with single CDT instance
|
> 647,797 43-break-insert --thread-group i1 main.c:76
Strange. There should be a -f option above, like this:
544,575 35-break-insert --thread-group i1 -f Producer.cpp:157
Are you using the class CommandFactory_6_8?
That is where that option is set.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Derek Morris
Sent: Friday, August 09, 2013 8:37 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debugging 2 programs with single CDT instance
On 9 Aug 2013, at 13:30, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Derek Morris
Sent: Friday, August 09, 2013 8:16 AM
To: CDT General developers list.
Subject: [cdt-dev] Debugging 2 programs with single CDT instance
Hi,
I am trying to debug two independent (but communicating)
applications from a single instance of CDT.
Everything works OK, except when setting a breakpoint.
When setting a breakpoint in a source file, CDT attempts to
set the breakpoint in both Debug sessions, which leads to a
warning be displayed "Breakpoint attribute problem:
installation failed".
GDB now sets a breakpoint as pending whenever it cannot
set it, so I wouldn't expect you to see such an error.
Are you using an older GDB (< 7.0)?
GDB 7.3.1
This is what gdbtraces reports in the 'wrong' debug session:
647,797 43-break-insert --thread-group i1 main.c:76
647,797 43^error,msg="No source file named main.c."
647,797 (gdb)
I understand that you cannot tell which debug session is
appropriate to set the breakpoint and therefore need to try
both, but it would be good to be able to filter the error, so
that if a breakpoint was set *somewhere* then no error would
be reported.
Does anybody have a suggestion where I should look to try to
implement this functionality?
MIBreakpointsManager.installBreakpoint()
In there, you will see a handleError() overridden method. That
is where the error gets set.
I guess you could check if the install count is greater than 0
and not set the error.
I'll take a look.
You'll also have to clear such an error if the breakpoint gets
successfully planted after an error was reported.
I haven't thought about it in-depth, but your idea sounds
like a interesting approach.
thanks!
thanks!
marc
Thanks
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev