From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zach Shaftel Newsgroups: gmane.emacs.devel Subject: Update 1 on Bytecode Offset tracking Date: Wed, 15 Jul 2020 19:10:32 -0400 Message-ID: <87a700fk3j.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37745"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.10; emacs 28.0.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 16 01:13:51 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jvqb0-0009jU-OB for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jul 2020 01:13:50 +0200 Original-Received: from localhost ([::1]:56080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvqaz-0002zr-Q6 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Jul 2020 19:13:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvqaN-0002A7-RX for emacs-devel@gnu.org; Wed, 15 Jul 2020 19:13:11 -0400 Original-Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]:44177) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jvqaL-0001iv-QA for emacs-devel@gnu.org; Wed, 15 Jul 2020 19:13:11 -0400 Original-Received: by mail-qt1-x830.google.com with SMTP id j10so3304331qtq.11 for ; Wed, 15 Jul 2020 16:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:message-id:mime-version :content-disposition:content-transfer-encoding; bh=VzABjtUazQNyDlV03D5ZYz9drRxbhM5FEBlpy9kUoDo=; b=NuO0X8ZbOf76EDGcHlaSNfWzymE/sePD4FwoWyu41Sp0bRIReIf3J9HLYMs/zUNFj5 /4c7wM0PZVzRa1dwIYbkqSkr5vIM9Gi4SxshrxmcQTttPCbp+F1W+7cK3XGuKRe/IPzv U2RfIR6nhjwUfyujBjqe0DXVcBbvlgEv2FNbSTL1PNYbZUZvyEtbq4RyscA99pSiLptv /t37Wk4qupTSl/v1WPDFAWpzMCFKH26A/4D7Otji3W/Ag5pZ185+GjcRFmKT9edqw9F0 DRdAlMH0vKlkojhO9zLhyTHA9fUUwY1KvtAtaBiH8BayIPOhrlCxoZ3DpuN+u7dLGbNy d4BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:message-id :mime-version:content-disposition:content-transfer-encoding; bh=VzABjtUazQNyDlV03D5ZYz9drRxbhM5FEBlpy9kUoDo=; b=YuiVV0xj/sFotZZqZom8rIrmMuTjfmHrpzEyjINP1RyTLOZLZAsfev82G7yd51HzBV Ez6expbwTJSg1rFf2zMGOXCmP140FevcBHNnVax1tmWjXlfJp3O5LA0Y0LmlCI0bo/v8 NrRjxQ+r0A0qb4ONNO7UFOGMBjY30QGvfaZj0dpTt5UoW2V+4daSccV8j8791zXMAWL+ KVqGwcXOV/sgCadMHhu+frk4s3tEekEBsKyo98DgsgS+jb1iV/DwTn8S/bBBDejHFgI+ vr+l/zRL8GYxU7YgW85WdR9AMvAnVmG4ZwCUzP2xB4kuPQytjggpndiLQb5Prvr1eW3I W9sA== X-Gm-Message-State: AOAM532nF8XW7QGWLXI40yQPOzAfM8JvgkRMn6P87SmtYKcp1VL+dDdQ ElceZOTuDFFv+aNILN0DedWGS39K/QfZgg== X-Google-Smtp-Source: ABdhPJxn8cbQBnEdM3nFgGT2DpV/MmP1zrU/37vFz5v6Lxmikz0JhsNTDvYNh876C1d/fQFrdSWalQ== X-Received: by 2002:ac8:6f26:: with SMTP id i6mr2311927qtv.61.1594854788178; Wed, 15 Jul 2020 16:13:08 -0700 (PDT) Original-Received: from arch-thinkpad ([37.120.205.235]) by smtp.gmail.com with ESMTPSA id r6sm4917926qtt.81.2020.07.15.16.13.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2020 16:13:07 -0700 (PDT) Content-Disposition: inline Received-SPF: pass client-ip=2607:f8b0:4864:20::830; envelope-from=zshaftel@gmail.com; helo=mail-qt1-x830.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252971 Archived-At:

Roughly weekly, we (I and Rocky Bernstein) will be sending status updates in this thread on my GSoC project to add source-code positions to Elisp traceb= acks.

Right now this project has two components,

  • re= porting bytecode offsets when there is an error, and
  • being able to map those offset into sour= ce locations.

feature/zach-soc-bytecode-in-traceback, feature/soc-byteco= de-in-traceback-reduced and feature/zach-soc-func= all-from-bytecode.

The first tracks offsets as part of the NEXT macro (advance PC). It ha= s a performance impact of ~7%. So far people have expressed concern over the degradation in performance, though I am not sure if anyone has used this and noticed a slowdown in use.

The second branch saves the offset only before a call. Therefore, the trace= back on all of the functions other than the current one are accurate, but the cu= rrent one is not accurate if the error happens in a byte op.

A number of people have made suggestions for how to speed up the code on th= ese branches. We have spent a lot of time trying to implement the more isolated changes that were suggested with little effect.

The third branch bypasses invoking Ffuncall from within exec_byte_code, and instead does essentially the same thing that Ffuncall does, right in t= he Bcall ops. This means the offset can be stored in the backtrace frame without the= need to make it globally accessible in the thread_state. Additionally, lexi= cally scoped compiled functions are passed directly to a recursive call of ex= ec_byte_code. The speed gained from that outweighs the overhead of t= racking the offset. But some changes are necessary to make it viable.

All of them print the offset next to function names in the backtrace like t= his: 

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...&quo=
t;)
    78 byte-recompile-file("/home/zach/.repos/bench-compare.el/test/te=
st-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)

(with varying degrees of accuracy, as described above). You can then M-x disa= ssemble the function to find the index and see which instruction made things go wro= ng.

If there are others who want to improve the code we have or follow through implementing any suggestion, we=E2=80=99d be grateful. Feel free to branch = off the code in Savannah and continue.

If we go with the second solution which just updates the bytecode offsets b= efore fu= ncall=E2=80=8Bs, which has negligible overhead, then we can probably= get this into master sooner. A comparison of the performance using Andrea Corallo=E2=80= =99s elisp-benchmarks.el can be found in this file.

Getting something of this nature into the sources takes time and careful consideration. The C changes for the reduced offset tracking are pretty sma= ll, but there is still a noticeable improvement in traceback information. Those= of us who care about better traceback location agree this is not ideal, but it= is better than the no-location situation that is there now.

So right now we are proposing just location information on calls, and then = we will gauge what people think after trying this, and if they would like more= we will pursue that further.

With respect to reporting offsets, using code from edebug we have a Lisp-Expression reader that will track source-code locations and store the information in a source-map-expression cl-struct. The code in pro= gress is here.

Information currently saved is:

  • Th= e expression itself
  • The exact string that was read
  • Begin and end point=E2=80=8Bs of th= e sexp in the buffer
  • source-map-expression children (for= conses and vectors)

source-map-fi= le. We are testing this on lots of files such as the lisp files in the GNU Emacs distribution. After this is done we will try hooking this into the compilat= ion process.

Feel free to contribute to all the links in this message and extend in the = areas mentioned. The sooner this gets done, the sooner we can move onto next step= s, toward the ultimate goal of line-and-column code locations in *Backtrace*.

=E2=80=8B- Zach and Rocky