Here's a scenario I ran into while working with adding of 
pathmap support to dbxgui. The Summary is a likley solution but
I'm primarily interested in documenting the problematic scenario
which would appear as a bug.

Change development platform to a remote host of type, say, Solaris-Sparc
using NFS.
Build it, debug it ... alls cool.
Now switch development to localhost and debug it ... things fail, pathmaps
don't work, bpts won't work etc.

Here's why. When building 'there' pathmaps will be automatically set up to
map /export/home to /net/here/export/home. When the project is built there
the working directory of the build will be /net/here/export/home/...
This information is encoded in the compiler, fed to the debugger and thence
to the IDE which pathmaps it to /export/home and accesses it here.

Then, when you switch to localhost and debug you end up debugging the same
executable that was built there 
    dist/Debug/SunStudio-Solaris-Sparc/pctposixexport
and has embedded in it paths of the from
/net/here/export/home/...
As a result breakpoints which are now on /export/home get rejected by 
dbx which expects paths to begin with /net/here/export/home.

The problem will fix itself if one does a full rebuild 'here', but given
that for debugging of large programs automatic "Build before run" is
impractical there's a window where things will mysteriously not work.

One possible solution is to have localhost have a redundant pathmap as well.
It's the same pathmap which would be generated if files were being
exported from 'here'. In a sense the machine 'here' becomes a remote
machine and indistinguishable from any other remote machine. 

Another approach that may only work for dbx is to drop any leading /
from paths sent to dbx. Then dbx will utilize a right-anchored best-match algorithm which was designed for helping differentiate between
    stop at         main/file.c:50
    stop at jill/project/file.c:20
But it's hard to evaluate all the implications of this.