emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging Emacs


From: Phillip Lord
Subject: Re: Debugging Emacs
Date: Sat, 28 Nov 2015 21:35:06 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> > But I will now stop writing comments to a text I didn't yet see, and
>> > let you work on it instead ;-)
>> 
>> 
>> It was at the bottom of the original email!
>
> I thought you were rewriting it for inclusion in etc/DEBUG.  Sorry for
> my misunderstanding.

Well, I wrote some text. I think etc/DEBUG would be the best place to
put it, but I just included it to see whether any one (probably you!)
thought it sounded sensible.


>> While I am mailing, I had one idea which might simplify debugging.
>> Currently, you need to break-point some function to get control to GDB
>> before you launch Emacs.
>
> Do you mean get control to GBD _after_ Emacs is launched?  If so, why
> do you need that?  You could set breakpoints where you need them
> before running Emacs, can't you?

You can, yes. And, if you are used to doing this, setting a breakpoint
*before* running Emacs probably seems natural.


>> Why not add a null function to Emacs core for the purpose?
>> Guaranteed never to be called from anywhere, does nothing, and with
>> a breakpoint could be added to .gdbinit. Then, after running Emacs,
>> "M-x break" would automatically pass control back to GDB without any
>> further set up.
>> 
>> Just a thought.
>
> Sometimes I don't want to set a breakpoint before running Emacs,
> because Emacs would hit that breakpoint many times during startup.  If
> this is the problem you needed to solve, then I use Fredraw_display
> for that purpose (I've added that to DEBUG at some point).  There are
> other similar functions which can be used in the same role.

Exactly. And you mention this in the DEBUG file. My text suggests the
"log" function from floatfns.c. But, in a "getting started" file this
adds complexity. You have to explain why it is necessary (because GDB
normally uses Ctrl-G I guess?), you have to explain to set a breakpoint
first, and how to do this.

Now, if we had a command, say `break', implemented in C, then added a
"breakpoint Fbreak" into .gdbinit, then all of this would happen
automatically. Under GDB, then "M-x break" or (break) Emacs would halt.
Outside M-x break would do nothing.

Clearly, nothing that can't be done anyway, and something that an
experienced debugger might never touch. But one of the joys of
emacs-lisp is that getting to a step-through debugger is really very
easy. I found it a little harder with the C core.

Phil





reply via email to

[Prev in Thread] Current Thread [Next in Thread]