bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

Zach Shaftel
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 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

Lars Ingebrigtsen
Zach Shaftel <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Sat, 17 Oct 2020 11:08:29 +0200
> Cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

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





Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#42499: [PATCH] Add Bytecode Offset information to Backtrace

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email]
> Date: Sun, 18 Oct 2020 10:11:33 +0200
>
> Eli Zaretskii <[hidden email]> 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.