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

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

[Dima Kogan]

Hi. I'm using a bleeding-edge build of emacs, although I think this is a
very old bug.

I just ran a Python program in $DIRECTORY:

  python3 program.py

python3 is in /usr/bin. There was a bug, the program crashed, dumped
core, and I want to debug it. I do this from the buffer containing
program.py (default-directory is $DIRECTORY, which contains program.py
and is NOT /usr/bin)

  M-x gud-gdb
  gdb --fullname /usr/bin/python3 core.sfmviz.py.1807941

It says this:

  /usr/bin/core.sfmviz.py.1807941: No such file or directory.

It works fine from the shell, outside of emacs. The issue is that
gud-gdb is changing default-directory to /usr/bin (where the binary
executable lives). But I never asked for that, and this is unexpected:
I'd expect it to do the same thing as that gdb command would do in the
shell.

Thanks

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Thu, 27 Oct 2022 16:52:32 -0700
> 
> Hi. I'm using a bleeding-edge build of emacs, although I think this is a
> very old bug.
> 
> I just ran a Python program in $DIRECTORY:
> 
>   python3 program.py
> 
> python3 is in /usr/bin. There was a bug, the program crashed, dumped
> core, and I want to debug it. I do this from the buffer containing
> program.py (default-directory is $DIRECTORY, which contains program.py
> and is NOT /usr/bin)
> 
>   M-x gud-gdb
>   gdb --fullname /usr/bin/python3 core.sfmviz.py.1807941
> 
> It says this:
> 
>   /usr/bin/core.sfmviz.py.1807941: No such file or directory.
> 
> It works fine from the shell, outside of emacs. The issue is that
> gud-gdb is changing default-directory to /usr/bin (where the binary
> executable lives). But I never asked for that, and this is unexpected:
> I'd expect it to do the same thing as that gdb command would do in the
> shell.

This is the documented behavior of "M-x gud-gdb":

  (defun gud-gdb (command-line)
    "Run gdb passing it COMMAND-LINE as arguments.
  If COMMAND-LINE names a program FILE to debug, gdb will run in
  a buffer named *gud-FILE*, and the directory containing FILE
  becomes the initial working directory and source-file directory
  for your debugger.

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.

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

[Dima Kogan]

Thanks for replying, Eli.


Eli Zaretskii <eliz@gnu.org> writes:

> 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?

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?

Thanks.

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 58826@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.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.

I think Eli is right here.

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

Indeed.  So any change would also need to be careful not to break
backwards-compatibility in relevant cases.

At the same time, users might not expect the change of directory to
depend on whether or not she says "python3" or "/usr/bin/python3".  So
to avoid just wontfixing this outright, here are some alternative ideas:

- Perhaps we could skip changing the directory if the prefix (in the
  above case "/usr/bin") is already in PATH?

- But that won't take care of the case where it is *not* in PATH.  So
  perhaps we should have even more heuristics to also see if it is some
  interpreter (under the assumption that interpreters generally don't
  live together with the source code that is being debugged)?

  IOW, if --fullname is some well-known value like "python3", we don't
  change directory by default.  We would need to consider if such a
  change would break anything for relevant use-cases, of course.

That's the best I could think of, at least.  If that is overcomplicating
things, I guess we will have to close this bug as wontfix, as
unsatisfying as that seems.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think I gave GDB commands to specify the file name
of each file that GDB would look at.  If there isn't a `set' command
to specify where to find the core dump, how about suggesting that
in a GDB bug report?



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, dima@secretsauce.net, 58826@debbugs.gnu.org
> Date: Mon, 14 Nov 2022 23:17:16 -0500
> 
> I think I gave GDB commands to specify the file name
> of each file that GDB would look at.  If there isn't a `set' command
> to specify where to find the core dump, how about suggesting that
> in a GDB bug report?

This is not about GDB commands, this is about the behavior of GUD when
invoking GDB to debug a program.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This is not about GDB commands, this is about the behavior of GUD when
  > invoking GDB to debug a program.

I see.

There are supposed to be GDB options it can specify on startup to get
the right behavior from GDB.  Is there some such option that is
missing from GDB?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, 58826@debbugs.gnu.org,
> 	dima@secretsauce.net
> Date: Fri, 18 Nov 2022 00:05:47 -0500
> 
> There are supposed to be GDB options it can specify on startup to get
> the right behavior from GDB.  Is there some such option that is
> missing from GDB?

No.  GDB behaves correctly and as expected.  The issue is with GUD,
specifically how GUD sets the default-directory of the buffer through
which the user interacts with GDB.

Here's the doc string which describes this subtlety:

  (defun gud-gdb (command-line)
    "Run gdb passing it COMMAND-LINE as arguments.
  If COMMAND-LINE names a program FILE to debug, gdb will run in
  a buffer named *gud-FILE*, and the directory containing FILE
  becomes the initial working directory and source-file directory
  for your debugger.  If you don't want `default-directory' to
  change to the directory of FILE, specify FILE without leading
  directories, in which case FILE should reside either in the
  directory of the buffer from which this command is invoked, or
  it can be found by searching PATH.

The above means that the default-directory of the *gud-FILE* buffer
will be different depending on whether at gud-gdb's prompt you type
the GDB command with the program to debug in its absolute file-name
form:

   gdb ... /foo/bar/baz ...

or you type

   gdb ... baz ...

and let GDB find 'baz' by searching PATH.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The above means that the default-directory of the *gud-FILE* buffer
  > will be different depending on whether at gud-gdb's prompt you type
  > the GDB command with the program to debug in its absolute file-name
  > form:

  >    gdb ... /foo/bar/baz ...

  > or you type

  >    gdb ... baz ...

  > and let GDB find 'baz' by searching PATH.

Indeed, that can happen.

But does GDB have a command to specify the file name of the core dump?
It ought to.  If it does, can you override that mistaken heuristic
choice by specifying the complete file name of the core dump?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, 58826@debbugs.gnu.org,
> 	dima@secretsauce.net
> Date: Sat, 19 Nov 2022 20:15:40 -0500
> 
>   > The above means that the default-directory of the *gud-FILE* buffer
>   > will be different depending on whether at gud-gdb's prompt you type
>   > the GDB command with the program to debug in its absolute file-name
>   > form:
> 
>   >    gdb ... /foo/bar/baz ...
> 
>   > or you type
> 
>   >    gdb ... baz ...
> 
>   > and let GDB find 'baz' by searching PATH.
> 
> Indeed, that can happen.
> 
> But does GDB have a command to specify the file name of the core dump?

Yes, it does.

> If it does, can you override that mistaken heuristic choice by specifying
> the complete file name of the core dump?

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Dima Kogan]

Richard Stallman <rms@gnu.org> writes:

> Could we fix this by adding a new option to GDB to specify the working
> directory?

This exists: you can "gdb --cd DIR"

But that doesn't matter: this is a gud issue. The complaint was that
running "gdb ARGS" in a shell sometimes doesn't do the same thing as M-x
gud "gdb ARGS", even with the same ARGS

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Could we fix this by adding a new option to GDB to specify the working
  > > directory?

  > This exists: you can "gdb --cd DIR"

I figured there would be one.  However, is that what we want in this case?
Do we want GDB to run with a different working directory, or only to
find the core file in that directory?

  > But that doesn't matter: this is a gud issue. The complaint was that
  > running "gdb ARGS" in a shell sometimes doesn't do the same thing as M-x
  > gud "gdb ARGS", even with the same ARGS

The question is, why not fix this with a change in GUD?  People were
talking about an obstacle to doing so, but I didn't see a clear
statement of what the obstacle was.  It seemed to be about whether GUD
can tell GDB to find the core dump in the right place.

If --cd enables GDB to find the core dump in the right place,
why not make GUD send that argument?

Does that fail to do the job right?



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, 58826@debbugs.gnu.org,
> 	dima@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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

It must be Emacs Lisp code that creates the *gud-FILE* buffer
and handles these relative file name.  Can't that code be changed
to DTRT?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, 58826@debbugs.gnu.org,
> 	dima@secretsauce.net
> Date: Wed, 28 Dec 2022 22:14:14 -0500
> 
>   > 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.
> 
> It must be Emacs Lisp code that creates the *gud-FILE* buffer
> and handles these relative file name.  Can't that code be changed
> to DTRT?

The argument here, and the original problem, is about what is "TRT".
For some (many) use cases, what the code does now is already TRT.  I
attempted to explain that up-thread:

   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.