[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Debugging 2 programs with single CDT instance
|
On 9 Aug 2013, at 13:53, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
>> 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.
>
No - but I am now!
Thanks
>
> ________________________________
>
> 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
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
