GNU bug report logs - #58826
29.0.50; gud-gdb can't find core file if executable is in a different directory

Previous Next

Full log

Message #14 received at 58826 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 58826 <at> debbugs.gnu.org
Subject: Re: bug#58826: 29.0.50; gud-gdb can't find core file if executable
 is in a different directory
Date: Fri, 28 Oct 2022 10:20:26 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 58826 <at> debbugs.gnu.org
> Date: Thu, 27 Oct 2022 23:29:37 -0700
> 
> > This is the documented behavior of "M-x gud-gdb":
> > .....
> > AFAIU, if you run the debugger like this:
> >
> >   gdb --fullname python3 core.sfmviz.py.1807941
> >
> > then GUD will not change the default-directory to /usr/bin, which I
> > believe is what you want.  GDB will then locate the Python executable
> > either in the current default-directory or by searching PATH.
> 
> OK. It's documented, but it's still not good. What if the executable
> wasn't in the $PATH?

Is that what happens in your case?

In general, you need in that case to change to the directory of the
executable, and invoke gud-gdb from there.

IME, the current behavior covers most of the use cases: either you are
debugging a program you are developing from its source tree, or you
are debugging an installed program that's on PATH.

> It's also really unintuitive to have an implicit change of directory
> here, and it would match most people's expectations if it was changed, I
> think. Do you know why we're doing that?

If you think about that, it's actually quite natural: it makes the
files you are likely to access from the debug session appear in the
current directory.

In any case, this is a long-standing behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.