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

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: stefankangas <at> gmail.com, 58826 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: bug#58826: 29.0.50; gud-gdb can't find core file if executable is in a different directory
Date: Thu, 24 Nov 2022 08:55:48 +0200

> From: Richard Stallman <rms <at> gnu.org>
> Cc: stefankangas <at> gmail.com, 58826 <at> debbugs.gnu.org,
> 	dima <at> secretsauce.net
> Date: Wed, 23 Nov 2022 18:16:27 -0500
> 
>   > No, because the default-directory of the *gud-FILE* buffer is already set by
>   > the time you get the GDB prompt.
> 
>   > You can, of course, "M-x cd" in the buffer.
> 
> Could we fix this by adding a new option to GDB to specify the working
> directory?  The gud.el could use that option
> if it sees that GDB's default choice for working directory
> would not be correct.

GDB already has a --cd=DIR option.  If the user wants, he or she can use
that by editing the GDB invocation command line at the gud.el's prompt.

However, there's a fundamental misunderstanding here: this is not about the
directory which GDB uses as its current directory, this is about the
default-directory of the *gud-FILE* buffer in Emacs.  That default-directory
is set by gud.el _regardless_ of what GDB considers as cwd.  The logic that
sets the default-directory of the *gud-FILE* buffer is entirely in gud.el.
Telling GDB to chdir to another directory will not affect the
default-directory of the *gud-FILE* buffer, and that was the OP's problem:
the fact that typing a relative file name was interpreted relative to a
directory he didn't expect.

Previous Next

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