From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Zach Shaftel Newsgroups: gmane.emacs.devel Subject: GSoC project - Improving ELisp Traceback and Debugging Information Date: Wed, 03 Jun 2020 17:42:27 -0400 Message-ID: <87eeqv6d30.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="30273"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.8; emacs 28.0.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 03 23:43:09 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 1jgbAD-0007mK-4c for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jun 2020 23:43:09 +0200 Original-Received: from localhost ([::1]:54890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgbAC-0003Nu-65 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jun 2020 17:43:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgb9c-0002uf-26 for emacs-devel@gnu.org; Wed, 03 Jun 2020 17:42:32 -0400 Original-Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]:43658) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgb9b-0007OD-9Z for emacs-devel@gnu.org; Wed, 03 Jun 2020 17:42:31 -0400 Original-Received: by mail-qk1-x734.google.com with SMTP id v79so3876355qkb.10 for ; Wed, 03 Jun 2020 14:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:subject:date:message-id:mime-version; bh=Ky5f22NCjGoox6NmTlj4f0aUxDHrQ9aHPFur0DQrENs=; b=WldCeIBHM3bZEm3Xy29uouqW+2hLrc6AsUYsGOBW3x+Q/LXhhB1ENjgtrs0KE2IHDm XEYRbcV02a2GygJhG5UTeoAxwMhNyBL7ii3Vh+GMx82vRd8/9lWkRgweSEJQmzSx9hP4 uoYWgSoTvI8B0xW1Dc9bkFyPHs9Y9JWgJvCYkKz2Ja3UkSyRDRGYRGDSrIq56UNOVO5a ZJI2G3y8gXR6oM0rhbpep9xrQqWIUES2EYtuI+bXlgA2mMqnoNAiiy44t2IlGlRR9Xzu aGnnhjp4tyNWBOmBSOKuSyZNyFwDuZaPG44CfQGhBrcjXMAM+uwMC4GS4mKI9dausquC tS6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:subject:date:message-id :mime-version; bh=Ky5f22NCjGoox6NmTlj4f0aUxDHrQ9aHPFur0DQrENs=; b=uLnpAum84WP4Fg8IbPGXSM2dv1dQaoLRtfu36V5HXgBRvgiNPQRr3IZ3+V9xId7aTq kKOG1t4XCzlRguM1aWgoL2XBeIGHeD3DYR0uzMIXi4gz0AD2VGntcUVfVy4x3Pvsay/x ibeAV9V0FFVNMkPKsR8N5eNJmS2LCAEzRlBfc+DwEWZXoxmd7k5qbwYI/OS6I+MxJcZo VPESZb+G29XHNRoTlDM6u3JHfLwyExptVswmNSw8JDfjZvzlGGjtLBbMT9c9tu3k8o6K viUIVIYjNupEcc29DZ02DGFDfGrCW9egQz+3hy2pFicaR898Yhj0X0qCakBP8oC061yT 0BmA== X-Gm-Message-State: AOAM532SwXmBOeQIq+dvajzgpQXOFR5YHI/a4Uo+BPz54wIVCvn8tSYM B2RIUcxBmuN2fHz+hJqRpxlZtixs3t8= X-Google-Smtp-Source: ABdhPJznIwP1d99QKwlMLPgR5wUMQPvDqtiTvwBPi7x/hWEExnuQoVzBiYfSJFhM1q/KRnlq7+5Juw== X-Received: by 2002:a37:9f44:: with SMTP id i65mr1788894qke.103.1591220549537; Wed, 03 Jun 2020 14:42:29 -0700 (PDT) Original-Received: from arch-thinkpad ([2604:2000:2f41:2d00::1]) by smtp.gmail.com with ESMTPSA id v59sm2876347qte.96.2020.06.03.14.42.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 14:42:28 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::734; envelope-from=zshaftel@gmail.com; helo=mail-qk1-x734.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN 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:251822 Archived-At: Hello all, This summer I will be working on improving ELisp traceback information for Google Summer of Code. My ultimate goal is to record the source location of calls so that this can be used by the backtrace, eg. buttons which jump to the exact function call which produces the error. The minimum goal however is to have the offset recorded while maintaining acceptable performance, and allow the backtrace to jump to the point in the disassembly where the error occurs. So far I've modified the byte-code interpreter to simply store the offset of each funcall in the backtrace specbinding frame, and modified backtrace.el so the sequence of offsets is printed alongside each respective call in the backtrace. It's available on the feature/soc-bytecode-in-traceback-specbinding branch on Savannah. Here's what the backtrace output looks like: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) 10 test-debugger() 6 call-test-debugger((110 117 109 98 101 114 115 0 1 2 3 4 5)) 9 call-call-test-debugger() load("/home/zach/ELisp/bad-stuff.elc" nil t) 513 command-line-1(("-l" "bad-stuff.elc")) 1482 command-line() 417 normal-top-level() The current implementation entails a performance regression (based on elisp-benchmarks.el on my machine, a ~10% slowdown), so it's not viable in the current state, but there's plenty of ways to improve on that. Any ideas would be appreciated. I've been looking at the scratch/accurate-warning-pos branch as well as prior discussions and am still evaluating different approaches to solving the task. It might be necessary to modify the way code is represented during compilation, be it simply with the annotated symbols as in that branch or with another more generalized form of object representation. The latter approach would be more versatile, but doing so while still preventing the compiler from hogging memory would be tough, and is broad enough that it's probably outside the scope of this project. I'd love to hear others' thoughts, advice, and comments on the project, and on what sorts of changes would be most desired for inclusion in Emacs. Thanks, Zach Shaftel