Setting the Source Lookup Path in CDT 3.0

[Hampus Edvardsson <hampus@xxxxxxxxxxxxx>]

One task that has become a lot more complicated in CDT 3.0 is setting the source lookup path (in situations where you are debugging an application on a different machine than it was compiled on). I was trying to explain the process to one of my users and realized that I needed a lot of steps with multiple screenshots just to be able to describe the process. I really thought I needed to send the same use case to this list as it works very well in exposing a usabilty problem, especially when comparing the process with how simple the same thing was in CDT 2.1.

/Hampus Edvardsson

---

Setting the Source Lookup Path in CDT 3.0

Hampus Edvardsson (hampus@xxxxxxxxxxxxx)

 

When an executable has been compiled with debug symbols on a different machine than the current host, the paths to the source files are likely to be invalid (since this path is often an absolute path).

 

Instructing CDT 3.0 to look for the source files in a different directory than the one specified is unfortunately ridiculously hard (it takes a total of eight steps through four or five nestled dialog boxes). These steps are shown below.

 

1. Press the button “Edit Source Lookup Path”, shown in the view where the source code is supposed to be.

 

2. In the dialog box that appears, select “Add…”.

 

3. In the next dialog box, select “Path Mapping” and press OK.

 

4. Now we are back in the previous dialog box, with a newly created “Path mapping”. Select this element and click the edit button.

 

5. This will open another dialog box, where we can name the mapping entry. This entry turns out to not be an entry at all, but actually a group of path mappings. To add a path mapping to this group, press the “Add…” button. (The group of path mappings can also be labeled for some reason…)

 

6. New we are presented with the dialog box where we specify the actual path mapping. In the upper text field we specify the path that was compiled into the executable. This is not filled in by default but left blank so that we must remember what the exact path was when we compiled the executable. In this case, it was “/root”. It also allows us to specify where we want CDT to look for these files on the host file system.

 

7. We want our users to store the source code in project directory associated with this launch. Unfortunately, CDT here provides a directory browser, with the desktop as its default location, resulting in a lot of pointing and clicking before we have reached the directory where the project is stored on our hard drive. (The dialog will also not remember this location when opened a second time.)

 

8. Now when we finally has specified the source mapping, and pressed OK in a total of four dialog boxes, we are returned to the main window again. If we managed to specify a correct path mapping, the result will look something like the picture below, and the current line of source code will be selected in the source view. If we made a mistake somewhere along this line, we will end up with a window looking like the one in the first view in the beginning of this document. Then we have to figure out where we made the mistake and repeat (more or less) the whole process.

 

Setting the Source Lookup Path in CDT 2.1

Contrast the behavior described above with how CDT 2.1 works.

 

1. In CDT 2.1, a much more readably page appears in the source view when a specified source file could not be found. It contains the complete path of the file it was trying to display, as well as instructions on how to specify an alternative path to use instead.

 

2. Pressing the button, displays the following dialog box. In this dialog, the compiled path has already been supplied by CDT (since it knows exactly what it is supposed to be). The only this we have to specify is the path on the host where we have located the source code.

And we’re done!