When starting gdb with a symlink in CWD it starts the executable in CWD, but after reloading the executable, typically after a rebuild, it is started at the destination of the symlink. This is rather impractical if you rely on the value of arg[0]. Steps to reproduce: --------- dalle@blahonga:~$ cat somewhere/foo.c #include <stdio.h> int main (int argc, char *argv[]) { puts(argv[0]); return 0; } dalle@blahonga:~$ gcc -g -o somewhere/foo somewhere/foo.c dalle@blahonga:~$ ln -s somewhere/foo bar dalle@blahonga:~$ gdb bar GNU gdb (GDB) 7.6.1-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/dalle/somewhere/foo...done. (gdb) r Starting program: /home/dalle/bar <<<< file on the command line /home/dalle/bar <<<< argv from the gdb command line [Inferior 1 (process 27285) exited normally] (gdb) ^Z [1]+ Stopped gdb bar dalle@blahonga:~$ touch somewhere/foo dalle@blahonga:~$ fg gdb bar r `/home/dalle/somewhere/foo' has changed; re-reading symbols. Starting program: /home/dalle/somewhere/foo <<<< file the symlink refered to /home/dalle/somewhere/foo <<<< something else [Inferior 1 (process 27295) exited normally]
I think this was probably fixed in bug #15415. *** This bug has been marked as a duplicate of bug 15415 ***