[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3650: M-x gdb unusable on Windows
From: |
Stefan Kangas |
Subject: |
bug#3650: M-x gdb unusable on Windows |
Date: |
Sat, 02 Nov 2019 07:04:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Jason Rumney <jasonr@gnu.org> writes:
> Jason Rumney wrote:
>> Kenichi Handa wrote:
>>
>>> By the way, I also installed gdb-6.8-mingw-3.tar.bz2. But,
>>> with "M-x gdb", pp and pr commands doesn't work. They print
>>> nothing. They do work when gdb is invoked from command
>>> line. Do you know what is wrong?
>>>
>>
>> I've often had problems in the past using debuggers under Emacs on Windows
>> (under Emacs 21 and early 22 development versions though, so I haven't tried
>> the new gdb-ui extensively), so I always use the command line.
>
> I just tried it, and it seems to be even worse than I remembered.
>
> Problem 1 is that the default directory of gdb is the directory where the
> Emacs
> executable is even though I started it from the source directory and specified
> oo/i386/emacs.exe as the executable to debug. This means that .gdbinit needs
> to
> be "source"d in manually. In addition, gud is unable to find source files that
> are not already being visited:
>
> (gdb) break fontset_find_font
> Breakpoint 1 at 0x10f9dd7: file fontset.c, line 527.
> (gdb) list :1
> No source file named in loaded symbols.
>
>
> Problem 2 is that Emacs output (including the results of pp and pr) is
> redirected to a buffer entitled *input/output of emacs.exe*, or at least
> that is what the intention appears to be. That buffer is populated as follows
> when gdb starts, and never updates:
>
> c:\GnuWin32\bin\sleep.exe: cannot read realtime clock: Invalid argument
> Process gdb-inferior exited abnormally with code 1
>
> Problem 3 is that there appears to be a menu toggle for disabling this output
> redirection, but it does not function. Instead, I see this in *Messages*:
>
> Symbol's function definition is void: gdb-use-separate-io-buffer
>
>
> Problem 4 is that enabling GUD tooltips results messages like the following:
>
> error in process filter: Args out of range: "", 0, -1 [2 times]
>
>
> Problem 5 is the general slowness. This one is probably down to Windows poor
> subprocess and pipe support, but the rest seem to be real problems within
> gud/gdb-mi.
This was reported 10 years ago.
Is this still an issue on modern versions of Emacs?
Best regards,
Stefan Kangas
- bug#3650: M-x gdb unusable on Windows,
Stefan Kangas <=