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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 28 Oct 2022 10:20:26 +0300

> From: Dima Kogan <[email-masked]>
> Cc: [email-masked]
> 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.