Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-user] Setting breakpoints in a remote C++ project

Ok - I'll go ahead and do it. I take it this should be treated as a CDT issue?

 

I'm not sure if it's your baby, but I actually posted another message a couple of days back about a problem with remote indexing, and trying to debug a problem where the dstore daemon appears to crash during indexing. I'd really appreciate a pointer on how to get some debug data out of it, and how to increase the heap size for the daemon? I have a hunch that's the problem.

 

From: ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: 13 July 2011 15:36
To: PTP User list
Cc: PTP User list; ptp-user-bounces@xxxxxxxxxxx
Subject: Re: [ptp-user] Setting breakpoints in a remote C++ project

 

I remember something now... I've run into this before actually.

There's some code in the CDT debugger that validates breakpoint locations, and it doesn't know how to deal with remote files, so it thinks the breakpoint would be invalid because the file has no local location. I don't think I got around to filing a bug for it.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Inactive hide details for Greg Watson ---07/12/2011 08:16:29 AM---Jim, It sounds like there is an issue with setting CDT breakpGreg Watson ---07/12/2011 08:16:29 AM---Jim, It sounds like there is an issue with setting CDT breakpoints using the RDT editor. RDT is part


From:


Greg Watson <g.watson@xxxxxxxxxxxx>


To:


PTP User list <ptp-user@xxxxxxxxxxx>


Date:


07/12/2011 08:16 AM


Subject:


Re: [ptp-user] Setting breakpoints in a remote C++ project


Sent by:


ptp-user-bounces@xxxxxxxxxxx





Jim,

It sounds like there is an issue with setting CDT breakpoints using the RDT editor. RDT is part of PTP, so I'd suggest you open a bug on that component.

Regards,
Greg

On Jul 12, 2011, at 7:58 AM, Jim Page wrote:

Hi Greg

Unfortunately that doesn’t work for me. If I select 'C/C++ breakpoints' and then toggle the breakpoint, nothing happens, and nothing is added to the breakpoint list - it just silently fails. If I select PTP breakpoints, the breakpoints are added in the UI, and the breakpoint list, but they are never hit.

If the debugger opens a window (eg when hitting main), I can add C++ breakpoints to that file, and they work. At the moment that seems to be the limit of what I can do! ie, I can't add a breakpoint to any file except the one containing the main() function, unless I step into it.

Thanks
Jim

From: ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
Sent:
12 July 2011 13:54
To:
PTP User list
Subject:
Re: [ptp-user] Setting breakpoints in a remote C++ project


Jim,

If you right click on the edge of the editor where the breakpoints are located, then select "Breakpoint Types", you should be able to switch to "C/C++ Breakpoints". After that, any breakpoints you create should work with the CDT debugger.

Regards,
Greg

On Jul 12, 2011, at 6:31 AM, Jim Page wrote:


Hi Chris.

You're right - I am debugging a normal (non-supercomputer) application, and the parallel debugger looks amazing but somewhat overkill for my situation. And I understand a lot better now which pieces go where in the architecture, CDT/RSE/PTP.

Since my last message I realized there's a way to select PTP breakpoints or 'normal' breakpoints, available in the right-click menu when you click in the source. PTP breakpoints insert ok into the 'remote' source, normal breakpoints don't … meaning that everything would hang together if I used the parallel debugger, but using the normal CDT remote debug tool doesn't; I'm sure this is due to the smoke and mirrors behind the scenes being used to map the remote files into the project, as you suggested. Maybe a 'remote' breakpoint type needs to be developed, a hybrid of your PTP breakpoint and the normal one?

I suppose the question is - who looks after the 'Remote C/C++ Project' work, you or the CDT guys, and is anyone interested in trying to get this feature to work? It's frustratingly close to being perfect! I'm tempted to have a go myself.

Thanks
Jim

From: ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent:
11 July 2011 13:54
To:
PTP User list
Subject:
Re: [ptp-user] Setting breakpoints in a remote C++ project

It sounds like you are using the regular CDT debugger rather than the PTP debugger. Is that the case?

CDT has the ability to do remote debugging using gdb server. I would suggest you use that assuming you're not doing any parallel debugging.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

<image001.gif>Jim Page ---07/11/2011 07:50:56 AM---Thanks for the response Chris. I expressed myself badly - I am not opening the file from the remote

<image003.png>
From:

<image004.png>
Jim Page <jim.page@xxxxxxxxxxxxx>

<image003.png>
To:

<image004.png>
PTP User list <ptp-user@xxxxxxxxxxx>

<image003.png>
Date:

<image004.png>
07/11/2011 07:50 AM

<image003.png>
Subject:

<image004.png>
Re: [ptp-user] Setting breakpoints in a remote C++ project

<image003.png>
Sent by:

<image004.png>
ptp-user-bounces@xxxxxxxxxxx






Thanks for the response Chris. I expressed myself badly - I am not opening the file from the remote systems view, I am opening it from the Project Explorer view within the Remote C/C++ perspective - sorry for the inaccuracy.


Given I am doing as you suggest, do you think the issue is related to my setting up with a remote debugger executable rather than a local one?


From:
ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent:
11 July 2011 13:42
To:
PTP User list
Subject:
Re: [ptp-user] Setting breakpoints in a remote C++ project

There is a subtle difference between files you open from the Remote Systems view and those you open from your project directly. When you open a file from the Remote Systems view, RSE downloads the file to a hidden project on your local machine and then opens it, and does some very weird stuff with the data it sends to the Eclipse resource system. It will not be identified at all as being in your project (it's in this other, hidden project as far as Eclipse is concerned, with a totally different EFS provider), so the usual debugger source mapping code will not ever map anything to it.

You'll have to open the files from the Project Explorer if you want source mapping to work.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

<image001.gif>
Jim Page ---07/11/2011 06:39:08 AM---Ladies and Gents, I am using eclipse indigo on Windows 7 (64) to build a moderately complex C++ app

<image005.png>
From:

<image006.png>
Jim Page <
jim.page@xxxxxxxxxxxxx>

<image005.png>
To:

<image006.png>
"
ptp-user@xxxxxxxxxxx" <ptp-user@xxxxxxxxxxx>

<image005.png>
Date:

<image006.png>
07/11/2011 06:39 AM

<image005.png>
Subject:

<image006.png>
[ptp-user] Setting breakpoints in a remote C++ project

<image005.png>
Sent by:

<image006.png>
ptp-user-bounces@xxxxxxxxxxx







Ladies and Gents,

I am using eclipse indigo on Windows 7 (64) to build a moderately complex C++ app on a linux (centos 5.3/64) host with 2GB RAM (nearly all available). I am using a 'Remote C/C++ Project', using 'Remote Tools' as a provider.

The problem: when debugging I am unable to set a working breakpoint on source code that I haven't stepped into. In more detail - I can open a source file from the project (from the remote explorer view), and the UI allows me to set a breakpoint, but the breakpoint is never hit. But if (for example when breaking at main()) the debugger opens the source file, I can successfully set breakpoints in that tab. Note: I have set the debugger executable as: 'plink <host> gdb', running gdb on the remote host as opposed to the local host.

In the eclipse editor UI, the difference between a file that works and a file that doesn't is that when you hover over the tab you see paths like this:

- working: c:\users\jim\work\trunk\rmnotifier\application\src\main.cpp
- not working: /rmnotifier/application/src/main.cpp

I added a debugger source path mapping: /mnt/work/trunk/rmnotifier/ => c:\users\jim\work\trunk\rmnotifier

In the breakpoints view - breakpoints that work appear as normal breakpoints do in non-remote projects, also when looking at the properties. Breakpoints that don't work are listed with "{Global: Root}" next to them, and when I look at the properties they are of type 'PTP Line breakpoint'.

Possibly it's down to the fact that I have set the debugger executable as: 'plink <host> gdb', and the remote gdb talks to the gdb server on the (same) remote machine. If I absolutely have to build a cross-compiler version of gdb to get this to work, then can you point me to some instructions on how to build this, or ideally download a built example? There are some ancient cross-compiler docs on the MinGW site but from the level of negative body language in the howto I can tell this is going to be a pain.

CDT: 8.0.0.201106081058
PTP: 5.0.1.201106271824
Eclipse: 3.7.0

Many thanks
Jim
_______________________________________________
ptp-user mailing list

ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user
_______________________________________________
ptp-user mailing list
ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user


_______________________________________________
ptp-user mailing list
ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user

_______________________________________________
ptp-user mailing list
ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user

_______________________________________________
ptp-user mailing list
ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user


Back to the top