[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36648: emacs signals under gdb - [Re: connecting to a lost server pr
From: |
Madhu |
Subject: |
bug#36648: emacs signals under gdb - [Re: connecting to a lost server process |
Date: |
Fri, 19 Jul 2019 07:23:39 +0530 (IST) |
* Eli Zaretskii <eliz@gnu.org> <838ssvwek9.fsf@gnu.org>
Wrote on Thu, 18 Jul 2019 18:24:54 +0300
>> Date: Thu, 18 Jul 2019 20:28:21 +0530 (IST)
>> Cc: 36648@debbugs.gnu.org
>> From: Madhu <enometh@meer.net>
>>
>> >From the point of view of elisp, no error should be signalled - it
>> >should be caught by the condition-case.
>
> You called those functions directly, from outside of the Lisp machine,
> so the condition-case machinery is not working.
The Lisp Language specifies how conditions are to be handled. The
Lisp machine can only be a virtual machine on which that lisp code
runs. If the behaviour of a piece of lisp code (however it is
invoked) isn't according to the lisp specification, it is a bug in the
implementation. The behaviour here can be deemed to be a bug in the
implementation of condition-case rather than a design-bug in
condition-case.
>> However there seems to be room for improvement around the "abort when
>> awaiting for input behaviour" - as there are other situations within
>> gdb which are not "really" error situations which unnecessarily abort
>> emacs.
>
> There are inherent difficulties that require this behavior, sorry.
I'm sure there is some way to mitigate it, though I probably will not
be able to find it.
>> M-x gud-gdb RET
>> gdb --args emacs --arg -Q --eval '(progn (load-library "custom")
>> (load-library "server") (setq server-name "emacs-test"))' RET
>>
>> =>
>>
>> |Reading symbols from emacs...
>> (gdb) show args
>> Argument list to give program being debugged when it is started is "--arg -Q
>> --eval \'\(progn \(load-library custom \) \(load-library server \) \(setq
>> server-name emacs-test \)\)\'".
>
> I suggest to use "M-x gdb", not "M-x gud-gdb". The latter is an old
> and semi-deprecated way of running GDB from Emacs.
[Unfortunately for me gud-gdb is the only way I can use gdb under
emacs. I was using M-x gdb in emacs19, but was unable to use gdb under
emacs for some time when it was replaced by gdb-mi - where it seemed a
superhuman adversary would rearrange my windows and impede my workflow
in myraid ways - until I discovered gud-gdb]
> I guess we can close this bug report?
Yes please.