How to get gdb on Linux to find source file for binary cross compiled on windows

Question

I am trying to debug an application that is cross-compiled on a Windows host for a Linux target.

The problem: Because the initial compilation is in windows the stored source file paths in the binary is of the form C:\Users\foo\project\.... On the Linux target I have put the source files under \home\foo\project\.... By default gdb does not find the source file because of the different path.

What I have tried so far:

1. Use "directory" command in gdb to give an exact path for the .c source file in the target Linux system where the app is being debugged. This works but unfortunately there are literally hundreds of files so this solution is unrealistic.

2. Use the set substitute-path C:\\Users\\foo\\project /home/foo/project command to have gdb substitute all prefixes. Note that the \\ seems necessary such that show substitute-path registers the right string. This unfortunately does not work. My guess is that the substitute-path command does not handle ms-dos style paths.

3. Tried separating the debug info out into a separate .debug file (see How to generate gcc debug symbol outside the build target?) and then using debugedit to change the paths with the command debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Unfortunately this does not work either. debugedit seems to work fine if the existing path is all UNIX/Linux like but doesn't seem to work with ms-dos style paths.

I have looked around stackoverflow and while there are similar topics I can't find anything that will help me. Would really appreciate any suggestions/help. I realize that cross compiling from Windows is a very roundabout way but can't avoid that for the moment.

Thanks

Answer 1

Although it's rather old question, I did encountered the same problem. I managed to resolve it but using sed on binary executable... (yeah, a 'bit' hack-ish, but did not found another way). With sed I've managed to replace symbols paths right inside the executable, the trick is that new path's length should be the same as the old one.

sed -i "s#C:/srcpath#/srcpath/.#g" ./executable

Be sure to make new path the same length, otherwise the executable will brake.

Answer 2

I also have this same problem. Your option 1 isn't as bad as you think because you can script creating all the 'directory' commands with something like this python code:

def get_directory_paths():
    return_array = list()
    unix_path = os.path.join('my','unix','path')
    for root, dirs, files in os.walk(unix_path):
        for dir in dirs:
            full_unix_path = os.path.join(root,dir)
            escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path)
            return_array.insert(0, "directory " + escaped_unix_path)
    return '\n'.join(return_array)

The downside is that if you have two source files with the same name in different directories, I don't think gcc can pick the right one. That worries me, but in my particular situation, I think I'm safe.

For option 2 (which I suspect would fix the aliasing condition from #1), I think the problem is that the substitutions are not ending with a "file separator" according to the linux so they aren't applied:

To avoid unexpected substitution results, a rule is applied only if the from part of the directory name ends at a directory separator. For instance, a rule substituting /usr/source into /mnt/cross will be applied to /usr/source/foo-1.0 but not to /usr/sourceware/foo-2.0. And because the substitution is applied only at the beginning of the directory name, this rule will not be applied to /root/usr/source/baz.c either." (from https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath )

I haven't tried anything like your #3 and I also considered something like @dragn suggestion, but in my situation the paths are not even close to the same length, so that will be an issue.

I think I'm stuck with #1 and a script, but if anyone has other suggestions, I'm interested options :-)