Re: [dsdp-dd-dev] Progress on remote target debugging in Windows, day 2

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Source lookup has proven itself a difficult problem to solve and even more difficult to get the user workflow "right".  The first step needs to be to figure out if the existing Eclipse mechanism of source containers, source lookup director and participants is enough to satisfy the GDB integration.  If it's not, it would be good to look into using the GDB commands (dir and set substitute-path). 

In addition to that, I agree that a listing all source files and their source mapping would be very useful to the user as a workflow improvement, and I would suggest we use the Modules view for that purpose. 
Cheers,
Pawel

Daniel Jacobowitz wrote:

On Tue, Feb 19, 2008 at 03:50:11PM +0100, Tobias Södergren XT wrote:
  

+	private String ensureSlash(String breakpoint) {
+            return breakpoint.replace('\\', '/');
+        }
    

I don't know if this is the same problem, but in case it is, here's
a suggestion which might be helpful.

GDB has a view of the executable, including which source files it
uses.  Eclipse has a view of the project including all its source
files.  The mapping between these two is not always straightforward;
GDB gets its list of source files from the debug info, not from the
filesystem.  So it can not always convert "../foo/bar.c" into
"c:\foo\bar.c" even if they're supposed to be the same file.

The most reliable solution is to send the same filenames to GDB that
you receive from GDB, if that's feasible.  Give GDB appropriate "dir"
and "set substitute-path" commands, have it find your source files,
use -file-list-exec-source-files to see the filenames and fullnames,
and pass those back to GDB when you're setting breakpoints.

I think that will also fix some of Eclipse's recurring problems with
setting breakpoints in "bar.c" when the executable contains multiple
files named "bar.c".