GNU bug report logs - #42499
[PATCH] Add Bytecode Offset information to Backtrace

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42499 in the body.
You can then email your comments to 42499 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zach Shaftel <zshaftel <at> gmail.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: [PATCH] Add Bytecode Offset information to Backtrace
Date: Thu, 23 Jul 2020 19:29:48 -0400

[Message part 1 (text/plain, inline)]

This patch adds the offset in a bytecode function's execution where an
error occurs to the *Backtrace* buffer, like this:

Debugger entered--Lisp error: (wrong-type-argument stringp t)
       string-match(t t nil)
    13 test-condition-case()
       load("/home/zach/.repos/bench-compare.el/test/test-debug...")
    78 byte-recompile-file("/home/zach/.repos/bench-compare.el/test/test-debug..." nil 0 t)
    35 emacs-lisp-byte-compile-and-load()
       funcall-interactively(emacs-lisp-byte-compile-and-load)
       call-interactively(emacs-lisp-byte-compile-and-load record nil)
   101 command-execute(emacs-lisp-byte-compile-and-load record)


If you disassemble one of the annotated functions, you can find the
instruction where the error occured.

A 'bytecode_offset' field is added to the 'specbinding.bt' struct, which
holds the offset in the execution of that frame's bytecode function. The
offset for the function being executed is stored in a field of the
'thread_state' struct, and updated from within 'exec_byte_code' before a
funcall. Then 'record_in_backtrace', called by Ffuncall, finds the last
frame and stores the offset there. The frame's offset is added to the
FLAGS plist argument passed by 'mapbacktrace'.

See further discussion about the limitations of the attached
implementation here:
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00365.html

My copyright assignment is still pending so I assume this can't be
merged until I hear back from copyright-clerk. The patch attached is a
simple diff without commit messages. I can add NEWS and Changelog
entries/commit messages if this ends up going through, but I may not be
able to get to that until next week.

-Zach

[bytecode-offset-in-backtrace.patch (text/x-patch, attachment)]

Message #8 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Zach Shaftel <zshaftel <at> gmail.com>
Cc: 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sat, 17 Oct 2020 11:08:29 +0200

Zach Shaftel <zshaftel <at> gmail.com> writes:

> This patch adds the offset in a bytecode function's execution where an
> error occurs to the *Backtrace* buffer, like this:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp t)
>        string-match(t t nil)
>     13 test-condition-case()
>        load("/home/zach/.repos/bench-compare.el/test/test-debug...")
>     78 byte-recompile-file("/home/zach/.repos/bench-compare.el/test/test-debug..." nil 0 t)
>     35 emacs-lisp-byte-compile-and-load()
>        funcall-interactively(emacs-lisp-byte-compile-and-load)
>        call-interactively(emacs-lisp-byte-compile-and-load record nil)
>    101 command-execute(emacs-lisp-byte-compile-and-load record)
>
> If you disassemble one of the annotated functions, you can find the
> instruction where the error occured.

Sounds useful, but probably somewhat less so since Emacs is moving to
natively compiling Elisp in Emacs 28.  Does anybody else have an opinion
here?

> My copyright assignment is still pending so I assume this can't be
> merged until I hear back from copyright-clerk.

This was in July, and I can't see your name in the copyright assingment
file.  Did the assignment process stall?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sat, 17 Oct 2020 12:32:43 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 17 Oct 2020 11:08:29 +0200
> Cc: 42499 <at> debbugs.gnu.org
> 
> > If you disassemble one of the annotated functions, you can find the
> > instruction where the error occured.
> 
> Sounds useful, but probably somewhat less so since Emacs is moving to
> natively compiling Elisp in Emacs 28.  Does anybody else have an opinion
> here?

I don't think we should start dismissing .elc compiled files just
because native compilation is on the horizon.  Some users might
legitimately decide they don't want their Lisp natively-compiled, or
may be unable to do so because of the GCC version they have
installed.  We should continue supporting byte-compilation features
for the next few versions at least.

> > My copyright assignment is still pending so I assume this can't be
> > merged until I hear back from copyright-clerk.
> 
> This was in July, and I can't see your name in the copyright assingment
> file.  Did the assignment process stall?

I have an email from Craig in late August saying the disclaimer is
being submitted to legal.  Suggest to ping Craig about this.

Message #14 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sun, 18 Oct 2020 00:15:42 -0400

[[[ 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 don't think we should start dismissing .elc compiled files just
  > because native compilation is on the horizon.  Some users might
  > legitimately decide they don't want their Lisp natively-compiled, or
  > may be unable to do so because of the GCC version they have
  > installed.  We should continue supporting byte-compilation features
  > for the next few versions at least.

We should continue supporting byte compilation indefinitely.
My machine is slower than what you are accustomed to,
and I think that native compilation could be a big slowdown.


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

Message #17 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sun, 18 Oct 2020 10:11:33 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I don't think we should start dismissing .elc compiled files just
> because native compilation is on the horizon.  Some users might
> legitimately decide they don't want their Lisp natively-compiled, or
> may be unable to do so because of the GCC version they have
> installed.  We should continue supporting byte-compilation features
> for the next few versions at least.

Yes, of course.  The only question is whether it makes sense to add new,
advanced features that is only relevant for .elc files at this point

> I have an email from Craig in late August saying the disclaimer is
> being submitted to legal.  Suggest to ping Craig about this.

Will do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sun, 18 Oct 2020 18:03:02 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: zshaftel <at> gmail.com,  42499 <at> debbugs.gnu.org
> Date: Sun, 18 Oct 2020 10:11:33 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I don't think we should start dismissing .elc compiled files just
> > because native compilation is on the horizon.  Some users might
> > legitimately decide they don't want their Lisp natively-compiled, or
> > may be unable to do so because of the GCC version they have
> > installed.  We should continue supporting byte-compilation features
> > for the next few versions at least.
> 
> Yes, of course.  The only question is whether it makes sense to add new,
> advanced features that is only relevant for .elc files at this point

I think it does, for those very reasons.  We cannot deprecate .elc
files, certainly not yet.

Message #23 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Zach Shaftel <zshaftel <at> gmail.com>
Cc: 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Thu, 13 May 2021 11:54:17 +0200

Zach Shaftel <zshaftel <at> gmail.com> writes:

> My copyright assignment is still pending so I assume this can't be
> merged until I hear back from copyright-clerk.

This was almost a year ago, and I can't see your assignment on file
yet.  Has the process stalled?

I've tried the patch, and it seems to work well.  It does add code in
the "hot path" of interpreting byte code, though, so I wonder whether
there's any noticeable performance impact?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #28 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Thu, 13 May 2021 13:25:35 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 13 May 2021 11:54:17 +0200
> Cc: 42499 <at> debbugs.gnu.org
> 
> Zach Shaftel <zshaftel <at> gmail.com> writes:
> 
> > My copyright assignment is still pending so I assume this can't be
> > merged until I hear back from copyright-clerk.
> 
> This was almost a year ago, and I can't see your assignment on file
> yet.  Has the process stalled?

Last I heard of that was last August, FWIW.

Message #31 received at 42499 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zshaftel <at> gmail.com, 42499 <at> debbugs.gnu.org
Subject: Re: bug#42499: [PATCH] Add Bytecode Offset information to Backtrace
Date: Sat, 12 Jun 2021 14:14:53 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This was almost a year ago, and I can't see your assignment on file
>> yet.  Has the process stalled?
>
> Last I heard of that was last August, FWIW.

And that was a month ago, so it seems unlikely that there'll be further
progress here, and I'm closing this bug report.  If progress can be
made, please respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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