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

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

Inactive hide details for Jim Page ---07/11/2011 06:39:08 AM---Ladies and Gents,  I am using eclipse indigo on Windows 7 (64) tJim 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


From:

Jim Page <jim.page@xxxxxxxxxxxxx>

To:

"ptp-user@xxxxxxxxxxx" <ptp-user@xxxxxxxxxxx>

Date:

07/11/2011 06:39 AM

Subject:

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

Sent by:

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


GIF image

GIF image


Back to the top