read debug symbols when source file was relocated

When using kcachegrind or just objdump -C -l -d somelib.so I noticed that some debug information in my shared libraries is not up to date, due to the copy process from the local file system of the build machine to the shared network file system of the installation.

The workflow is:

the build machine checks out the sources to /workspace/build/PROJECT/VERSION/dirs_with_sources
builds locally with -g
after building copies the sources to /software/PROJECT/VERSION/dirs_with_sources and the built shared libraries to /software/PROJECT/VERSION/InstallArea/ARCHITECTURE/lib

When I now open the shared libs with objdump -C -l -d somelib.so I see debug symbols like:

0000000000001a89 <_GLOBAL__sub_I_somesource.cpp>:
_GLOBAL__sub_I_somesource.cpp():
/workspace/build/PROJECT/VERSION/subdir/subsubdir/src/somesource.cpp:33
    1a89: 48 83 ec 08           sub    $0x8,%rsp
    1a8d: be ff ff 00 00        mov    $0xffff,%esi
    1a92: bf 01 00 00 00        mov    $0x1,%edi
    1a97: e8 a4 fb ff ff        callq  1640 <__static_initialization_and_destruction_0(int, int)>
    1a9c: 48 83 c4 08           add    $0x8,%rsp
    1aa0: c3                    retq

The filename here cannot just be copy and pasted as I don't have the build directory mounted on my user machine and need to replace /workspace/build by software.

This is annoying enough but dramatically fails when running e.g. kcachegrind where the source lookup just fails. (And I assume other debug tools that are meant to help me navigate between source code and build output will encounter similar problems).

Is there a general way to deal with debug symbols of relocatable files? I assume this should always be an issue when shipping a binary version of a library with debug symbols.

EDIT:

What I have used as workaround and would like to avoid as general solution:

mount /software to /workspace/build: a (kcachegrind) user might not have the permissions to create /workspace
recompile from source to have fixed debug information: This may demand more compilation time (and possibly user-disk) than a user is willing to invest (that's partially why we have the build machine and the network installation in the first place).

Solution

@tom-tromey's comment for gdb is also what works for kcachegrind. In the menu

Settings→Configure KCachegrind→Annotations→Add

One can add additional search paths, so specifying /software/ there is enough to get sources found. I have not yet tested what happens if similar sources exist in the search path (in the original example, multiple versions of the same source file exist in differently versionned directories), but in practice the search from /software/ is anyway too slow (too many subdirectories to search). For this reason I'm now using /software/PROJECT/VERSION/dirs_with_sources in that menu.

From how I understand the docs, this kcachegrind search path does not do the same as gdb's substitue-path (which would probably be better suited in the example here).