From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Date: Thu, 19 Mar 2020 18:05:33 -0400 Message-ID: References: <20200319203449.GA4180@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101586"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 19 23:06:30 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 1jF3J8-000QKc-CO for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 23:06:30 +0100 Original-Received: from localhost ([::1]:43672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF3J7-0003og-3w for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 18:06:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58102) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF3IK-0003Fu-KM for emacs-devel@gnu.org; Thu, 19 Mar 2020 18:05:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jF3IJ-0003NJ-3o for emacs-devel@gnu.org; Thu, 19 Mar 2020 18:05:40 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18557) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jF3IH-0003M3-Hk; Thu, 19 Mar 2020 18:05:37 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BF0DA1006FC; Thu, 19 Mar 2020 18:05:36 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DCC79100275; Thu, 19 Mar 2020 18:05:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1584655534; bh=ugNP4LE2TXornEiJgvXDMIUSiyvHNUgLYjYQ9PbgYsU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=D+X3ishw6FT973gMry/h7ydiJUA/XzfREasc/d4WtJNCGcEB/t3CCp8gR6LaiiuDX wbsdgyLbmIKPTA77TM5xMzk3OajZ194pHojXLsL0G+yvkICJ6oRPxtY3SBEOTcbyg7 C7e83rDuRkMKTX7vgu30/r1i7EXNKWdO7i2B3/KjXqnN+eEY+NY3iBsFmkQzMQZCTz XOuwnjp5vAm9e2uy7wuezuCfAjNQFD6kJDoVY4vstDy1hycuIogFVn6NOA1A1OT3Ev QhLIJQ5ZccHc76hoqjeyHVWkEJgxsIFYdXBnhTDWJqNrXekVCWgxWMlGgfX+s2Qdue yvNL1A3SmGNFg== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9EB6A1202FC; Thu, 19 Mar 2020 18:05:34 -0400 (EDT) In-Reply-To: (Rocky Bernstein's message of "Thu, 19 Mar 2020 16:56:45 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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:245593 Archived-At: >> "More precise line numbers" is a misconstruction, even though I've used >> such language myself in the past. Line numbers don't come from a >> physical instrument which measures with, say +-1% accuracy. CORRECT >> line (and column) numbers are what we need. > A bytecode offset is exact and accurate. I think he was talking about line-number info in byte-compiler warnings (where the info comes from the source code, not from the backtrace). Currently we use a hack that gives us approximate locations which can be wildly off-the-mark. > Right now this information unavailable. I think the interpreter uses > C pointers stored in a register. So just recording the bytecode > offset is a little bit of a slowdown, but not that much. Indeed. If it's too high we could make it conditional on a boolean variable. > I doubt it would even register as %1 slower. Reminds me that another project could be to try and speed up function calls. The difficulty here is that we don't really know what's the main source of the cost, so there's a good chance that any specific attempt will give disappointing results. It'd still be useful in helping us getting a better idea of what it is that takes time. > But just that would open the way for improvements. This is doable by a > Summer student - Stefan thinks it trivial. Just recording this info in the backtrace (at a minor performance cost) is indeed very easy. > But tas you point out there is overhead in getting it accepted and > into GNU Emacs. Right. Until this info is actually usable by tools like the debugger, the code would inevitably be #ifdef'd out unless it has zero-cost which seems unlikely. > Having access to the bytecode offset in a traceback there next are > several options. At the lowest level there is just showing that along > with a disassembly of the bytecode. > And that I believe that is also doable by a summer student. Agreed. Stefan