From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2025 15:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, acorallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Gerd =?UTF-8?Q?M=C3=B6llmann?= , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Andrea Corallo , Paul Eggert , Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.173920058721208 (code B ref -1); Mon, 10 Feb 2025 15:17:02 +0000 Received: (at submit) by debbugs.gnu.org; 10 Feb 2025 15:16:27 +0000 Received: from localhost ([127.0.0.1]:51938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thVWK-0005Vw-0z for submit@debbugs.gnu.org; Mon, 10 Feb 2025 10:16:27 -0500 Received: from lists.gnu.org ([2001:470:142::17]:39894) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thVWH-0005Vg-6e for submit@debbugs.gnu.org; Mon, 10 Feb 2025 10:16:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1thVW9-0006m1-O4 for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2025 10:16:15 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1thVW4-00009M-UY for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2025 10:16:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739200565; x=1739459765; bh=xRKKespnMrFGIYLo2P3nJ0yD0qDCKsP9kzXBBx+ywsQ=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=Jbf/VHpHjbYvBBNOz4Skm2zeOUGy5jsWFklVSVZ9b3F+AsQn9xKFAXjg0RmlGcA4x ujFLNVZ9R8zDkJihBw/s1Vp9tCcjNDhvT/xxgRcsGQsHUH6GtBiNq8k3CoVMfgB3r3 Yd7LpMtshI+TTz4hjf2XJ8YKbji5VvUdw41W0LEugBvb5m96HW1C5vXVTtSGpJdKqW ub6Y9Xpqss1nk4lTJ0SwukVplwzk5p5Vpsp8Em9POoh7DyH9OwY6H7a/BPIPFJfTZf t7KGQQZZO3BqWt3t+26rzb5W4oHGGOxn/ElRWjKabGojEknPSLkwcfk/9vYgUnGiO/ OGvXYg7SNCGKA== Date: Mon, 10 Feb 2025 15:15:59 +0000 From: Pip Cet Message-ID: <8734glomp9.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8b2deea9c3dcfe9e219e903664a877b466466eb2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=79.135.106.29; envelope-from=pipcet@protonmail.com; helo=mail-10629.protonmail.ch 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Currently, I'm aware of three known issues which would potentially result in live objects not being traced, which may lead to crashes that are very hard to debug. These are: 1. Bytecode objects violating the stack limit prosaically called HORRIBLE_ESTIMATE will fail to scan some of their excessively-large bytecode stack if interrupted by GC in execution. 2. Nativecomp code is sometimes compiled without -fomit-frame-pointer and uses %rbp as a general-purpose register: if said nativecomp code calls SETJMP directly, and setjmp() "scrambles" the frame pointer register, as it unfortunately does on most systems, the "scrambled" general-purpose value will not be traced and will not pin or keep alive its referenced object. 3. setjmp buffers in general are allocated using igc_alloc_handler, which does not scan the setjmp buffer conservatively. As it is unpredictable which callee-saved registers might contain live references, we need to scan the setjmp buffer conservatively. That still won't scan the stack pointer or frame pointer if they are "scrambled", so we must also ensure the frame pointer is never omitted in compiled code. Note that there are good reasons we're not seeing frequent crashes due to these bugs: 1. doesn't happen because most bytecode objects are small (and nativecomp is often in use). 2. affects only nativecomp functions calling setjmp directly, not those calling intermediate Emacs C code (which saves the %rbp register on the stack where MPS would see it). 3. Most likely requires aggresssive link-time optimization options to cause bugs. My idea is to propose three stop-gap patches for these issues as soon as this has a bug number; more satisfying patches will require help from bytecode/bytecode GC experts (Mattias), the nativecomp maintainer (Andrea), and a potential rewrite to always keep jump buffers on the C stack (Paul). My hope is that once these stop-gap patches are installed, it's a good point to call again for general testing of the feature/igc branch, under certain restrictions and with specific instructions to reduce the possibility of data loss due to crashes (e.g. run in GDB, set a breakpoint on kill, don't use TTY signals, xwidgets, unusual toolkits). I hope that "PGTK" and "WIDE_EMACS_INT" can be removed from the list of build constellations expected to be unstable ASAP. The branch will continue to contain bugs and we can't take any responsibility, but at least avoiding those known bugs seems to result in a usable work environment here, and it might be a good opportunity to regain some of the early testers who were too frustrated by stability issues to let them know that we've fixed some of them. Thoughts? Pip From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2025 19:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , Andrea Corallo , 76180@debbugs.gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173921438623561 (code B ref 76180); Mon, 10 Feb 2025 19:07:02 +0000 Received: (at 76180) by debbugs.gnu.org; 10 Feb 2025 19:06:26 +0000 Received: from localhost ([127.0.0.1]:52518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thZ6v-00067w-Nc for submit@debbugs.gnu.org; Mon, 10 Feb 2025 14:06:25 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:40376) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thZ6t-00067f-NT for 76180@debbugs.gnu.org; Mon, 10 Feb 2025 14:06:24 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 9C08D3C011BDB; Mon, 10 Feb 2025 11:06:17 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id oypa2izNqYVH; Mon, 10 Feb 2025 11:06:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0E07F3C00FA92; Mon, 10 Feb 2025 11:06:17 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 0E07F3C00FA92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1739214377; bh=bTi49T5RGDfZQt8D8rNK1qN3ElT2AEG62IF9n/yUk8M=; h=Message-ID:Date:MIME-Version:To:From; b=oaPp4TSF3TYYyBdFbmKYQFESUVg31sYpPLFAh7pedKqEMDfXV25yl1dDdUfIWX2M5 s5Woaqelhz1LlLIyAmgE5VlEtyU5cgIHImENQE2BF6EDEOstXs/pgS6NK91fu/4SnY t1Nn1xfKAvZ7PuNaA+PymQhrE0RTwMej9v5G9agvSufTag5axoMOw3fnkV6rV7jvrS tyVvozLixwFWfut9pICUX/4VvlWT6SWCfv92WBHzfC3xh2eYGDVjNhGYLaz04U8uEb vE5NltBjEUSMSTErM5Sy60PhotIuiZECikEdiwvJtaGP+qjthg3qTbJUaKS+5m9ETo MJNWdrUGsq0Rw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id R5-Sq8lD_L6n; Mon, 10 Feb 2025 11:06:16 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id D92B53C011BDB; Mon, 10 Feb 2025 11:06:16 -0800 (PST) Message-ID: Date: Mon, 10 Feb 2025 11:06:16 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <8734glomp9.fsf@protonmail.com> Content-Language: en-US From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBlQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYCAwEC HgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUCZiLOewUJHWQLDAAKCRDtl+kOYqp+NHGE D/9Wmbk+cAaQsYLPGBvyzIjZIRzo/V2p3ZwckVA1VEQivx5azu1cs86qDoVIe45AtwmKOvdV wTQd/QeglkZR6D2YPW7UR/7emajyJZZcy+etVTDKoaw1i6/hmd/CpGjUeUSvgoPs6nYR+1lo pSXTpaGrh1W0qQHalSkOOwCHG3HtGk9Ve2AERDUYxmcn8/eZHb7xpUJEJMBBI1bx/zcw1EtB rjsQ1R1faJ/r/7LPAyV36RLvnbX69PylHKQEbJoaY9aUb2Vpm63ni3FeTA7/3jpPvaSRWHJh vPYx6Fm2Ln8pI0Yf/W2B8QMiPTnF/LnH2kvUcf9VXm+1mQJ3fBFU25HZwBhuqZ24IeKymPEt BUMQAum97Dto0jSgR2OUvX7z+twhpQEgRGBzPHYwDi4SxF5Z4Q5Y7B7a++HP9tIxG6CVFIwI 4xVaZud18bPa0YBL+cISmMgxq7h7yoVXl6u3pm9Yiv+W6Lp9QGN8Rw1VuJMOoFCYuoxG8mXO TA5b1jvlQ32gHFFhqErDAhNJRsfgrpe9Gok4Ycp+rWljbvS5Wrl0uth5MP7FbaHN2kmTZibq KXAd//IqczhDyU6qnW6ao+h4iDBDgYgRbQjmToX/vmIdEMzvPGqWXKhe/q1TYMuOO+IfP+bI fyPFH29nVN/o9c4J7myeKvv3HKSXdSVjlh2V787BTQRMgHJkARAApoXrvxP3DIfjCNOtXU/P dwMShKdX/RlSs5PfunV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVaU2O49T3qsOd1 cHeF52YFGEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDXexF67upeRb2vdHBjYDNe ySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBnkkcaTbiI9Pst0GCc2aiznBiPPA2W QxAPlPRh3OGTsn5THADmbjqY6FEMLasVX8DSCblMvLwNeO/8SxziBidhqLpJCqdQRWHku5Xx gIkGeKOz5OLDvXHWJyafrEYjjkS6Ak6B5z6svKliClWnjHQcjlPzyoFFgKTEfcqDxCj4RY0D 0DgtFD0NfyeOidrSB/SzTe2hwryQE3rpSiqo+0cGdzh4yAHKYJ+UrXZ4p93ZhjGfKD1xlrNY DlWyW9PGmbvqFuDmiIAQf9WD/wzEfICc+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69a Hyvhq36z4zctvbqhRNzOWB1bVJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUXL+2+ SF99Kjy753AbQSAmH617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaPG43flEs1UR+1 rpFQWVHo1y1OO+sAEQEAAcLBfAQYAQgAJgIbDBYhBH43kqnYrPfWM7wViO2X6Q5iqn40BQJm Is58BQkdZAsMAAoJEO2X6Q5iqn40Q68QAJ9GubS/ej30Vc4idoZdc0IyMcL7kQJbMohF+Tyn ZE+TGn9WvzP10yLyzoI0vNlcNfP92d2MS//pFjOuANb5mwyiEYA+rDZIdS4ZZpHxCs2sxMC4 afLCf3kv4aMnTeBvb9na403dlczz9cAacvsmniSFdpb1+BzMpYbybglU5oYMGhYT2nnCRjXN 6S2nKYt4mjJeeOuxHrdeqQQdVBNYeNfTcPePeqvZ2+bD6u9yxZtaV+wxdpqglosQvjqhOYz7 h50/ZTSq70/npoCq44TzdJKttaYvlW6ziRz0g4RRAqZyoxjYXiy5qj8r8zXJuB11ApZCGuKn /usbji9RYbflAhxFeh4LMmpDVi6BrF30b73Md59K7PuEKN1NxzlWiqqQHZZ9momN0GXLPcGq 4uyfq7yVEy7wP5PMOh6oqscKklE3gFQtq0P1Ki0xqdF6Fq5LPJc+0Db2CYkVIy7Xaa/f74I3 sOfQfEeDylVXR5iDfUJEYv/0DYhOr7q5/0b1kh3M4wkrB4C5jVNHjIIj+RsAK90c3t38OhAl jiSN7Bkwy24Afy8eIu6wWzvhnsQGpZPB+IffmxT1wkTy8UxZKjUWV0C82iphVgCUUi2f9sDV Q/tNcwVWmOS+gdv9Wk6tdGeM+Ee+Qs6YG05jcSoajzF0TL07ajLcayRq2j1Os2CtQ8qu Organization: UCLA Computer Science Department In-Reply-To: <8734glomp9.fsf@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2/10/25 07:15, Pip Cet wrote: > a potential rewrite to always keep jump buffers on the C > stack (Paul). Another possibility would be to change igc_alloc_handler so that jump buffers on the heap are scanned conservatively. Both possibilities have merits; I am not sure which would be better. From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2025 19:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , Andrea Corallo , 76180@debbugs.gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173921544426645 (code B ref 76180); Mon, 10 Feb 2025 19:25:02 +0000 Received: (at 76180) by debbugs.gnu.org; 10 Feb 2025 19:24:04 +0000 Received: from localhost ([127.0.0.1]:52560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thZNz-0006vg-Fi for submit@debbugs.gnu.org; Mon, 10 Feb 2025 14:24:03 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:23035) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thZNw-0006v6-GB for 76180@debbugs.gnu.org; Mon, 10 Feb 2025 14:24:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739215433; x=1739474633; bh=6Foh49RgUYb301yE7QF1ZgJ2MJ4ZNlha3ACWJuE9ZLU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=jq1faFHbKSXLotieZNKOhW8sFE2jDcbwQ4QLc1s3XaJN0KFkCzPYtHYIfggjcyPYY G2XcbPNWC6zxtfSJd0lfQs51cZBsJYDKZoyGT74LlD4Uix3w6Y6BudyvAPMpDEUi1r nT5zhqNAW+gNBmL0KbwRBk51cc5Z3RB7zLRn4vb3+Honev0lbOy2x2XCgO79xqA071 jkW9/0UvZJ5k4YsfpXZaXVvgA3WeutBXdDVSqvDLxccmJvjmvrVnk2YU0q+ndoBVTo 2ZqfQHWn/ynboKC67mghWgFPa65EZ9uTiWude9+TVxVoSBQ0IXpO6SDkmz7+dSjkjJ iXw+1gPD9O64A== Date: Mon, 10 Feb 2025 19:23:49 +0000 From: Pip Cet Message-ID: <87zfitk3ix.fsf@protonmail.com> In-Reply-To: References: <8734glomp9.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c1ae3ba2178cce2f2861f7bb1e5865c8d258884c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Paul Eggert" writes: > On 2/10/25 07:15, Pip Cet wrote: >> a potential rewrite to always keep jump buffers on the C >> stack (Paul). > > Another possibility would be to change igc_alloc_handler so that jump > buffers on the heap are scanned conservatively. Thanks! That's the stop-gap patch, yes: turning it into an "ambiguous" root. > Both possibilities have merits; I am not sure which would be better. (Note that MPS does not allow ordinary heap objects to be scanned conservatively, just roots; and while it does allow roots to be protected with memory barriers, we don't make use of that yet. My understanding from reading some comments in the MPS code is that it's strongly optimized for not having additional large unprotected roots in addition to the C stack). My main argument for preferring the (slightly harder) solution of keeping the jump buffers on the C stack is that the handlerlist could shrink once again; right now, a large handlerlist never shrinks and treats many disjoint areas as a permanent ambiguous root, IIUC. As my hope is to make GC more frequent and use protection more, large unprotected roots seem like a problem right now. Pip From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 06:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: mattiase@acm.org, 76180@debbugs.gnu.org, acorallo@gnu.org, eliz@gnu.org, eggert@cs.ucla.edu X-Debbugs-Original-Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , bug-gnu-emacs@gnu.org, Andrea Corallo , Eli Zaretskii , Paul Eggert Received: via spool by submit@debbugs.gnu.org id=B.173925451316719 (code B ref -1); Tue, 11 Feb 2025 06:16:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2025 06:15:13 +0000 Received: from localhost ([127.0.0.1]:53721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thjY8-0004LL-FN for submit@debbugs.gnu.org; Tue, 11 Feb 2025 01:15:12 -0500 Received: from lists.gnu.org ([2001:470:142::17]:36224) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thjY5-0004Kj-Hc for submit@debbugs.gnu.org; Tue, 11 Feb 2025 01:15:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1thjXz-00026j-Vv for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2025 01:15:04 -0500 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1thjXx-00030s-0U; Tue, 11 Feb 2025 01:15:02 -0500 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-ab7d7f0a2cfso119929366b.3; Mon, 10 Feb 2025 22:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739254498; x=1739859298; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=oqvdSNTEYGY/UPLIPey7f3rF3HARtUP3NSQEvzymLUg=; b=S+uvN3eZ7TtoLJqzzWOMXymKzd8dCCRRw18aT4Sm+kmG5TTSW0cCMJc4rVdQb5HXUj E8+hlG1l1n5MZoYMMcJrn7ZtzEtiHuCdgrxE1F4K/HH1ce3pmG6X7Fk+LfJ9vuXPoDpE v3hGTn4fKR3iI26yLvcE29nlPylTVFD2WOBBh+jCkBWHwiM5QiKpMKacaeVLdil/7UlK p+KvMIf4ukdJjyQK8YKRUOGMQmyjgzpPQ5mG3mw6WpOy4rO+mCaB8YY+uRi8VVdeqlwE FeFUOCB3h153kPqBuXhEB9gNKlutSkv6IFNoWlJRtt0OcGt5keJZFEz4/q76GFsHnOBD hasQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739254498; x=1739859298; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oqvdSNTEYGY/UPLIPey7f3rF3HARtUP3NSQEvzymLUg=; b=C4Q3o5RCcHkWZoVCcpGqhQ5tm4esIGkWwYCTIjtfM44QCptLZXks9z5dHtQocwZj5V UhL/Zq8Aua+Ft1n5oJbtNfq0mvy80HLFhVB58U5pd4Ds7SGxIHAqOzU/2MKkAzfc5BBG ikn8Gbp2trT7FirFrAi32Vc8L8QlbMF+8XHiylWx3qUpR5EImuj0QVIZmWPh+jaBFnlr TNMOkmehQCgszav94/vAJbD2tbo3fwoRXwyQYHplmlMK6dnviBxm6CAP4KTrJH9tfXom zNw3mr1lfSYlLV88DLpfN3cRLxFxgsh1fbSoWKNiDpbwYYnOW6Env2IMjABVpXQZ4yua JNfg== X-Forwarded-Encrypted: i=1; AJvYcCUFtqQf8n7TAArPWVQP6s3iHaeUNdA3puWqrSD81eMjIIxgB8Kgec9jMhgFUE/01IZrU7PzBg==@gnu.org, AJvYcCVgt+eAvwZFc1JGJzxig1dv6AeXQLKAPOG5oLckRPxfR9ZsSa9TR1s1CY08jG33rk9hUEzaZa7CMg==@gnu.org X-Gm-Message-State: AOJu0Yy3V9B3r3u74eURXdz8dAq3mj+xSWcbVEpHfCPEM0/EAvpIbr/N WTbsrTif+UVFK/W/emf7y9WjP/3kTfcR7gm0ATBxRxxDIREXArYYCT8SLA== X-Gm-Gg: ASbGnct8A4F3SeL0QOyvdedx44tef17I7m7SJPs3XOl6xHv5E5pMlSiEubaVhCYjjvN ffmN+q+xP+yOc/DIjUDYLq8kGCu7P7wpK44rWBWrGMWkHw8bH9QuDGdXt+cd+RLa6ad7JTLf1F6 LxdSYiibNLSBdOoACxGb3KHpSmPttnDZ70sbgBZqbetpSGbbuBi18NKzf2RKvxktGwvFzC9RGEQ l+AtdzCdCIQqBkobKXyqVO+GGr8LO4tqaMJUESFgfFcbbIhLRkg6/Jz5lFfCVADS7MZgQZj5ybC J0O+fGBAfwLwGq7M/kFW8q0GVZ7J+83WC5yA11+RopihwIKjEcdw+Mca3PhywTA6Qyw7/GG5fIu mtb+lnQEvKTdFrg/sAMeRLJk= X-Google-Smtp-Source: AGHT+IF3P2pVlPU+tJVJJuCu1Dp8q1wDXhsQAzTV9u+oD2Vz/DOVPjggM1GGRM3pO6emX5aBsBmqHQ== X-Received: by 2002:a17:907:c91e:b0:ab7:94ee:eebb with SMTP id a640c23a62f3a-ab794eeefabmr1030611366b.14.1739254497794; Mon, 10 Feb 2025 22:14:57 -0800 (PST) Received: from pro2 (p200300e0b707040041ceee5518f31cf0.dip0.t-ipconnect.de. [2003:e0:b707:400:41ce:ee55:18f3:1cf0]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab7aab8d8fasm569095966b.58.2025.02.10.22.14.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Feb 2025 22:14:57 -0800 (PST) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <8734glomp9.fsf@protonmail.com> References: <8734glomp9.fsf@protonmail.com> Date: Tue, 11 Feb 2025 07:14:55 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x630.google.com 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_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Pip Cet writes: > 1. Bytecode objects violating the stack limit prosaically called > HORRIBLE_ESTIMATE will fail to scan some of their excessively-large > bytecode stack if interrupted by GC in execution. The current bytecode stack design is not really my thing, TBH. But I haven't followed what has been happening the last decades, so what do I know. There were times back then when I allocated byte code stacks using alloca for each frame, which of course implies that the maximum stack size was known at the time. (The idea behind that was to use conservative stack marking and so on.) Why that isn't the case now, I don't know. Or maybe I just didn't find it. Also, I'm not sure if that is still the case, but it might be worth checking if an overflow of the large stacks that are currently used (500K or so) is detected. From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 18:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, acorallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17392987304384 (code B ref 76180); Tue, 11 Feb 2025 18:33:02 +0000 Received: (at 76180) by debbugs.gnu.org; 11 Feb 2025 18:32:10 +0000 Received: from localhost ([127.0.0.1]:58571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thv3J-00018e-VA for submit@debbugs.gnu.org; Tue, 11 Feb 2025 13:32:10 -0500 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:59553) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1thv3H-00018E-Tv for 76180@debbugs.gnu.org; Tue, 11 Feb 2025 13:32:08 -0500 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5de6e26db8eso5619882a12.2 for <76180@debbugs.gnu.org>; Tue, 11 Feb 2025 10:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739298721; x=1739903521; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=/z9EYfR+CKY53xf1DX+dpFexhVFCQvwhWWpIsYbJ4LE=; b=iD+LLhGyd1fFhIsNZkzqehSQL9quCQ1dZxScY9PmM3MF+qCMFfq5IlaRhAVucPNZNO X6zNAIugmWUP31TrrkChXyig5fXl+m77fTCYbQefGUAKkRBR0ijZKoY8JM1PAwqeIPxf 2ULcfT15xt1xrJ4+fwWZV00HioGTQboXoSE0tlABLhrrLr4yPWxskWE+h3XaJLSV61Jq vtrZj286IvmNR2uVWtE2+uP0niJ6qXr7U+/BTy1MwFWrMI0IU49FRI5ppdVxjVrqH5vN bfaDKkmt9rcLrBkwVJ53hjaiSy5fNRe/xiU7cgTUkhVW2x6uEw6RjSJByZOzsX6pMgjV B9IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739298721; x=1739903521; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/z9EYfR+CKY53xf1DX+dpFexhVFCQvwhWWpIsYbJ4LE=; b=B7aYVmfZAn0AZAUjFggzYARzS+qYnfAgkPVBPYvMQm2pUCzWatU/Pjr7pDzF7p9Ryo 9iY2eKtVWySgNOKJh0RalK5TMi7gcKqoVPQj6zt8r7TSYd91Wi20GZPsY7MvtQ0109ru SWJZJs8ffwCYPwMzrFFMTlplL2aV5KZpQ+gqw7N5ehlgDo9g0qnOr/9MMXIAfZp+JoYg NKnSRs0AWmp4yJHUaklA9T0JqNxtoNxBqIgX5Oq1XnQViPch42zbgmArY9CyEWsZh8aX cADiL0tbkr05rl0WUsHW3+LO5DNPkldLpuoZH4ZOu2tbT9JuwHZ4hbX0DfDb5Eg60an8 bz+Q== X-Forwarded-Encrypted: i=1; AJvYcCVhU2KWadvH3eBE34U8GpZzmP8bh/37kljKTykB8fe5DKHLF3PxNyOZzr89pGe52kTZcqgc8A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyqvBx7XgxMwNQ600VOOv8a2uVZ9Vffgrqmbaq7BwDgZNaOXy51 JCzDsuwVG4LAkO1RrAEU7PbPY0vLgJ/YSnUM6KMp8Ejr5PAVGT616O0GdrcQUnMasMsTfNoLbXE T51GCAu2zwslWp/k+TSopa92sgjs= X-Gm-Gg: ASbGncuSC24v9rwQP7SoaYFSQYro560P+A8R3usTWoAVO+Xd970Z8fsuXy8wKlU9E1o tRTg/A9Uv+0+EeOQZ4HzhbXg9FZqH7+jeKu0hp5O7rYoHOV/QM1fomAcmmJFmqpXx5M5Ni47Iwa Y= X-Google-Smtp-Source: AGHT+IF0/Dnt/kMjsdVQqVA/ZdUx5LhSRzlJsw7oLjc9MGlyghQMZgTN/eY/yXw6XtVZuznPbjNo0ehKkLGlqvmAKV8= X-Received: by 2002:a05:6402:2383:b0:5de:481a:cbc1 with SMTP id 4fb4d7f45d1cf-5deaddb9197mr256190a12.16.1739298721383; Tue, 11 Feb 2025 10:32:01 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2025 10:32:01 -0800 From: Stefan Kangas In-Reply-To: <8734glomp9.fsf@protonmail.com> References: <8734glomp9.fsf@protonmail.com> MIME-Version: 1.0 Date: Tue, 11 Feb 2025 10:32:01 -0800 X-Gm-Features: AWEUYZk4fNzj2k1Ay7uxBk495Qm1EuWhtSzzQLK50khs7GaGM62V0vln2STYyAA Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > My hope is that once these stop-gap patches are installed, it's a good > point to call again for general testing of the feature/igc branch, under > certain restrictions and with specific instructions to reduce the > possibility of data loss due to crashes (e.g. run in GDB, set a > breakpoint on kill, don't use TTY signals, xwidgets, unusual toolkits). > I hope that "PGTK" and "WIDE_EMACS_INT" can be removed from the list of > build constellations expected to be unstable ASAP. > > The branch will continue to contain bugs and we can't take any > responsibility, but at least avoiding those known bugs seems to result > in a usable work environment here, and it might be a good opportunity to > regain some of the early testers who were too frustrated by stability > issues to let them know that we've fixed some of them. > > Thoughts? I don't have anything specific to add, but the above sounds like a good plan to me. Meanwhile, we also continue seeing other useful bug reports trickling in. Thanks again for working on this. From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 20:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, eliz@gnu.org, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17393050026539 (code B ref 76180); Tue, 11 Feb 2025 20:17:01 +0000 Received: (at 76180) by debbugs.gnu.org; 11 Feb 2025 20:16:42 +0000 Received: from localhost ([127.0.0.1]:58956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwgT-0001hP-Pc for submit@debbugs.gnu.org; Tue, 11 Feb 2025 15:16:42 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:37335) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thwgQ-0001h3-SB for 76180@debbugs.gnu.org; Tue, 11 Feb 2025 15:16:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739304991; x=1739564191; bh=PTPR4uPCXHnPOVNH2ZtyHeWnmh+l/2FBjxQc2UauC3Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=LfmY9Gt69MQapttOP1p8Z2HlFyY+F3B6Jax0gHZPSGOQNyTkyi9+QHdWIQt8R/lOb /azYCOy5yM+VWmflMv58QTv7vl6mlzsSqy5rxtO80cg6ECkjijuQtMacWnTrgmWRYS pnublxcc8dMgF3ngzzA1k8fDGTyC9X2Ypm5+tuIxMd3nIgGidKn8fuD1OPbFHmHNZh wBET/GrJWwTLz4FN4jJ1OPbFkvFvrVcI8a9/c44jWkcquydXG1SwWuNsiQfBt9qRl+ qs/H85mTAXzFhSE2kZt/8AZhnVnhuemsn7yHSQz44mMLBokmomI4AsyhF3Yi/Cq8CC 2gV0lkggB9dyA== Date: Tue, 11 Feb 2025 20:16:21 +0000 From: Pip Cet Message-ID: <87seokgruy.fsf@protonmail.com> In-Reply-To: References: <8734glomp9.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5df2167d38c33a98164e66ab08bcabd9a2824f34 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Stefan Kangas" writes: > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text > editors" writes: > >> My hope is that once these stop-gap patches are installed, it's a good >> point to call again for general testing of the feature/igc branch, under >> certain restrictions and with specific instructions to reduce the >> possibility of data loss due to crashes (e.g. run in GDB, set a >> breakpoint on kill, don't use TTY signals, xwidgets, unusual toolkits). >> I hope that "PGTK" and "WIDE_EMACS_INT" can be removed from the list of >> build constellations expected to be unstable ASAP. >> >> The branch will continue to contain bugs and we can't take any >> responsibility, but at least avoiding those known bugs seems to result >> in a usable work environment here, and it might be a good opportunity to >> regain some of the early testers who were too frustrated by stability >> issues to let them know that we've fixed some of them. >> >> Thoughts? > > I don't have anything specific to add, but the above sounds like a good > plan to me. Meanwhile, we also continue seeing other useful bug reports > trickling in. Well, here are the patches. I tried for a while to actually produce the bugs they attempt to fix, but those efforts weren't successful. As these bugs would be a bit subtle, that's not overly surprising. I've decided against putting HORRIBLE_ESTIMATE in lisp.h because then we'd probably have to explain what it is :-) >From 3cc41ab8ba5dda51774157dea5a976b931bf6a90 Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH 1/3] [MPS] Force nativecomp code to be compiled with frame pointers If nativecomp code keeps a reference to an MPS object in %rbp and calls setjmp, the reference will be scrambled and cause crashes if MPS moves or frees it. * lisp/emacs-lisp/comp.el (native-comp-compiler-options) [HAVE_MPS]: Add "-fno-omit-frame-pointer". --- lisp/emacs-lisp/comp.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el index 20b9c140228..86944b1a645 100644 --- a/lisp/emacs-lisp/comp.el +++ b/lisp/emacs-lisp/comp.el @@ -91,7 +91,8 @@ native-comp-bootstrap-deny-list :type '(repeat regexp) :version "28.1") =20 -(defcustom native-comp-compiler-options nil +(defcustom native-comp-compiler-options + (cond ((featurep 'mps) (list "-fno-omit-frame-pointer"))) "Command line options passed verbatim to GCC compiler. Note that not all options are meaningful and some options might even break your Emacs. Use at your own risk. --=20 2.48.1 >From 2c8c6f8013aaf6a80ba0e97b99e8bc156c31b3ff Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH 2/3] [MPS] Refuse to read byte-code objects with deep stack= s HORRIBLE_ESTIMATE in igc.c provides an upper limit on how deep a byte code object's stack can be and still be handled appropriately by igc. Enforce that. * src/alloc.c (Fmake_byte_code): * src/lread.c (bytecode_from_rev_list): Error out rather than creating a crashable byte-code object.- --- src/alloc.c | 5 +++++ src/lread.c | 5 +++++ 2 files changed, 10 insertions(+) diff --git a/src/alloc.c b/src/alloc.c index 7bad029b858..f8bcb1ef717 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -3820,6 +3820,11 @@ and (optional) INTERACTIVE-SPEC. =09 && FIXNATP (args[CLOSURE_STACK_DEPTH]))) error ("Invalid byte-code object"); =20 +#ifdef HAVE_MPS + if (XFIXNAT (args[CLOSURE_STACK_DEPTH]) >=3D 1022) + error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMA= TE!"); +#endif + #ifndef HAVE_MPS /* Bytecode must be immovable. */ pin_string (args[CLOSURE_CODE]); diff --git a/src/lread.c b/src/lread.c index e8cd689d794..67c1bbe5f7b 100644 --- a/src/lread.c +++ b/src/lread.c @@ -3483,6 +3483,11 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Obje= ct readcharfun) =09 || NILP (vec[CLOSURE_CONSTANTS])))))) invalid_syntax ("Invalid byte-code object", readcharfun); =20 +#ifdef HAVE_MPS + if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >=3D 1022) + error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMA= TE!"); +#endif + if (STRINGP (vec[CLOSURE_CODE])) { if (STRING_MULTIBYTE (vec[CLOSURE_CODE])) --=20 2.48.1 >From ad35aecca5c6270faeaff03cae4ff682d7503b35 Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH 3/3] [MPS] Ensure sys_jmp buffers are scanned ambiguously * src/igc.c (igc_alloc_handler): Use 'igc_xzalloc_ambig', not 'alloc'. --- src/igc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/igc.c b/src/igc.c index 9ed5c983a5d..17816c3a74c 100644 --- a/src/igc.c +++ b/src/igc.c @@ -4491,7 +4491,14 @@ igc_alloc_blv (void) void * igc_alloc_handler (void) { - struct handler *h =3D alloc (sizeof *h, IGC_OBJ_HANDLER); + /* struct handler contains a jmp_buf, which means it must be scanned + ambiguously in case one of the registers stored in the jmp_buf + refers to an MPS object. + + On Windows 64, jmp_buf is also 16-byte aligned, which causes + trouble with the MPS default alignment. + */ + struct handler *h =3D igc_xzalloc_ambig (sizeof *h); return h; } =20 --=20 2.48.1 From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2025 20:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, eliz@gnu.org, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17393056578503 (code B ref 76180); Tue, 11 Feb 2025 20:28:01 +0000 Received: (at 76180) by debbugs.gnu.org; 11 Feb 2025 20:27:37 +0000 Received: from localhost ([127.0.0.1]:58994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwr2-0002D5-Sa for submit@debbugs.gnu.org; Tue, 11 Feb 2025 15:27:37 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:28545) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1thwr1-0002Co-0E for 76180@debbugs.gnu.org; Tue, 11 Feb 2025 15:27:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739305648; x=1739564848; bh=twnHeDoGu3SCzRpMB1OCgYygSBga+q29zF81as9E1hg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=CInA8vjDZVCxHaqMBotgCaz96ExR+rB5lv2qlENw0BPIOJ0F96+l+tzn6uy1besa5 5YwUCjhKonopWYLhbCLAjh8I+5NeJRl28uCoRenIZ4rr7LqK+V3EzEzpej/VYnscqO MsnXRlpwUMYyCNVZVVAcinI92KNtfFKko9wP4/wJZzfMEInqIiZNy6yzRZgOn9WoV5 UyTnsda8ORM/KRrs3mJDqb01ojrnW4GWmWLlH8fTJJSSUKnnSs/rdUqwM8Gxg57kIA b0q58Gf+rMcoh6jYYVod9K4v7GPRJJ595yH/on2ccY/WJKETYTa68S1VSfaTxEb+1v LC5xz4LDXTSOA== Date: Tue, 11 Feb 2025 20:27:23 +0000 From: Pip Cet Message-ID: <87msesgrci.fsf@protonmail.com> In-Reply-To: References: <8734glomp9.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3cb44149289adf1efd654f7486969a750aae1505 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > diff --git a/src/lread.c b/src/lread.c > index e8cd689d794..67c1bbe5f7b 100644 > --- a/src/lread.c > +++ b/src/lread.c > @@ -3483,6 +3483,11 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Ob= ject readcharfun) > =09 || NILP (vec[CLOSURE_CONSTANTS])))))) > invalid_syntax ("Invalid byte-code object", readcharfun); > =20 > +#ifdef HAVE_MPS > + if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >=3D 1022) > + error ("Byte-code object uses too much stack, increase HORRIBLE_ESTI= MATE!"); > +#endif > + > if (STRINGP (vec[CLOSURE_CODE])) > { > if (STRING_MULTIBYTE (vec[CLOSURE_CODE])) > --=20 > 2.48.1 Sorry, this hunk wasn't the one I meant to send. This one needs to be applied after it: diff --git a/src/lread.c b/src/lread.c index a638b6eec8e..ae312874574 100644 --- a/src/lread.c +++ b/src/lread.c @@ -3576,7 +3576,7 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Objec= t readcharfun) invalid_syntax ("Invalid byte-code object", readcharfun); =20 #ifdef HAVE_MPS - if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >=3D 1022) + if (size > CLOSURE_STACK_DEPTH && XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= =3D 1022) error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMA= TE!"); #endif =20 to fix the obvious problem :-) From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Feb 2025 12:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17393637493454 (code B ref 76180); Wed, 12 Feb 2025 12:36:01 +0000 Received: (at 76180) by debbugs.gnu.org; 12 Feb 2025 12:35:49 +0000 Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiBy0-0000te-Ie for submit@debbugs.gnu.org; Wed, 12 Feb 2025 07:35:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52332) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiBxx-0000tO-PK for 76180@debbugs.gnu.org; Wed, 12 Feb 2025 07:35:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tiBxr-0008Ot-C6; Wed, 12 Feb 2025 07:35:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZqfiURlKlxazUuchKS8b7b/PNmnd5ZXTBKOjlIbJiw0=; b=EOOIYN3/BUpg JbCc8tY/NBmtakWiz5a/v6ntTadFAgXuriHUNYj48y8Nq2477KzrNW5dHNdntS1oqx3wR8m7RDQ7Q eerTvvMTQVjppMdo+OppqVtuojJjarTO1DofIkp/jtDSR4IOBW7EwC3kDZUaqWxLcZ11j0IlzTLik wavKUfUfS2axI2/WoRncV1/OD1NBSNKUPqyuzLOm0PGs21Waf1iAnjSy8LpxDhOso+C+qy9ZLHizj EOXBxuBUsLX0ayYgIYyhetusMetwUomFzvpykUl4LYCbFXp8NRVHRn6cq0evsMpYFq60gLO++kJ/n aI9+jvRDgCs1zPYp6vWbaQ==; Date: Wed, 12 Feb 2025 14:35:24 +0200 Message-Id: <86y0ybuyr7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87msesgrci.fsf@protonmail.com> (message from Pip Cet on Tue, 11 Feb 2025 20:27:23 +0000) References: <8734glomp9.fsf@protonmail.com> <87msesgrci.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 11 Feb 2025 20:27:23 +0000 > From: Pip Cet > Cc: 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, acorallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org > > Pip Cet writes: > > > diff --git a/src/lread.c b/src/lread.c > > index e8cd689d794..67c1bbe5f7b 100644 > > --- a/src/lread.c > > +++ b/src/lread.c > > @@ -3483,6 +3483,11 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Object readcharfun) > > || NILP (vec[CLOSURE_CONSTANTS])))))) > > invalid_syntax ("Invalid byte-code object", readcharfun); > > > > +#ifdef HAVE_MPS > > + if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022) > > + error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMATE!"); > > +#endif > > + > > if (STRINGP (vec[CLOSURE_CODE])) > > { > > if (STRING_MULTIBYTE (vec[CLOSURE_CODE])) > > -- > > 2.48.1 > > Sorry, this hunk wasn't the one I meant to send. This one needs to be > applied after it: > > diff --git a/src/lread.c b/src/lread.c > index a638b6eec8e..ae312874574 100644 > --- a/src/lread.c > +++ b/src/lread.c > @@ -3576,7 +3576,7 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Object readcharfun) > invalid_syntax ("Invalid byte-code object", readcharfun); > > #ifdef HAVE_MPS > - if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022) > + if (size > CLOSURE_STACK_DEPTH && XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022) > error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMATE!"); > #endif > > > to fix the obvious problem :-) Can't we figure out how far to scan, instead of using some more-or-less arbitrary constant? The comments in scan_bc seem to imply that figuring out the distance to scan should be possible? From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Feb 2025 12:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , acorallo@gnu.org Cc: gerd.moellmann@gmail.com, mattiase@acm.org, eggert@cs.ucla.edu, stefankangas@gmail.com, 76180@debbugs.gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17393640834535 (code B ref 76180); Wed, 12 Feb 2025 12:42:02 +0000 Received: (at 76180) by debbugs.gnu.org; 12 Feb 2025 12:41:23 +0000 Received: from localhost ([127.0.0.1]:33159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiC3O-0001B5-RT for submit@debbugs.gnu.org; Wed, 12 Feb 2025 07:41:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56846) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiC3L-0001Ao-5A for 76180@debbugs.gnu.org; Wed, 12 Feb 2025 07:41:20 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tiC3E-0002IX-F9; Wed, 12 Feb 2025 07:41:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JHzWHQ0pUioucrne3ojRJ5MzTw3qrQvXQ3KzvO5j9cQ=; b=h/KZKK4ZnWUm qah5ZBXbV/OoKzLLAd6he/7QiXc8PdhlaiKw1f+2hlvmgx3N+7pcr9ePvTH+Tivwb89kNyc5q5aGg XGqV0Zt1vOYvSCAZxzxFK2i7vdPFTqIvjoP+kRN37/InU2DqBBZNwcQTnyfqWnlwku6TU//Z80l3f koE7qT9GRfs9wMwIDLQtRH2+c9slH34mvbKXBxCNZgSkD21kYw5+Q0EYqKOLCGNOnh7Ddt63z2U8J IVkE4yZ6utPixUvDt0h08MscrkX4DsMdP5J076FAqigehKf1JoZAUxP3MXJtFLWa3SRUjieDDS2b9 VkqVj29HFnA2zECArVTtFA==; Date: Wed, 12 Feb 2025 14:40:18 +0200 Message-Id: <86wmdvuyj1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87seokgruy.fsf@protonmail.com> (message from Pip Cet on Tue, 11 Feb 2025 20:16:21 +0000) References: <8734glomp9.fsf@protonmail.com> <87seokgruy.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 11 Feb 2025 20:16:21 +0000 > From: Pip Cet > Cc: 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, acorallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org > > --- a/lisp/emacs-lisp/comp.el > +++ b/lisp/emacs-lisp/comp.el > @@ -91,7 +91,8 @@ native-comp-bootstrap-deny-list > :type '(repeat regexp) > :version "28.1") > > -(defcustom native-comp-compiler-options nil > +(defcustom native-comp-compiler-options > + (cond ((featurep 'mps) (list "-fno-omit-frame-pointer"))) > "Command line options passed verbatim to GCC compiler. How about always using -fno-omit-frame-pointer, not as part of a user option? We could put it in some variable for those few (who?) who might want to enable -fomit-frame-pointer. I see no reason to expose this to users, do you? Alternatively, maybe the nativecomp code could be modified not to use RBP? Andrea, WDYT? Thanks. From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2025 12:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173953628927140 (code B ref 76180); Fri, 14 Feb 2025 12:32:01 +0000 Received: (at 76180) by debbugs.gnu.org; 14 Feb 2025 12:31:29 +0000 Received: from localhost ([127.0.0.1]:47449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiuqu-00073a-OF for submit@debbugs.gnu.org; Fri, 14 Feb 2025 07:31:29 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:30889) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiuqr-00073H-5q for 76180@debbugs.gnu.org; Fri, 14 Feb 2025 07:31:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739536278; x=1739795478; bh=jBEG4el/Fp2DX/FZZLjHxvPkby3e3RyJoD91EJQK80I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Mrz/HXJd8Cqe1jBungD8wsDgCVdvyp/NvxXuHUxtJTg72/10Pu1brdZod0dTlleAG WQoQCgwdrHdAc/699i8Ohh9q7xnpt3Ymh5MdL0+JAtcH477H4dkFOZM6Tnokwc2Udw 1CMD1xhrUo1R8MlY3nXoIBKs2PEBVYWjVcAZAgZuY3NyV+AWWM8ddH79/LpmltKgyY iXLvP4wwVMCeMlDtUMq3Qr05nJHCnO/g9NqK2nwFy5EFo7qPi+Ls0e7w+wjjv1XX58 9tGfzddNbbqRl7JhvUsU4DubqZG31i8Vg6YrHhRN1AEeZEE8Cv7YF+4y4EvxFU+E0g yGJic00V4KImA== Date: Fri, 14 Feb 2025 12:31:15 +0000 From: Pip Cet Message-ID: <87jz9sn1xt.fsf@protonmail.com> In-Reply-To: <86wmdvuyj1.fsf@gnu.org> References: <8734glomp9.fsf@protonmail.com> <87seokgruy.fsf@protonmail.com> <86wmdvuyj1.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3c110bcf89ee242a200c02266315e53fa8d31d02 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Tue, 11 Feb 2025 20:16:21 +0000 >> From: Pip Cet >> Cc: 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, a= corallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org >> >> --- a/lisp/emacs-lisp/comp.el >> +++ b/lisp/emacs-lisp/comp.el >> @@ -91,7 +91,8 @@ native-comp-bootstrap-deny-list >> :type '(repeat regexp) >> :version "28.1") >> >> -(defcustom native-comp-compiler-options nil >> +(defcustom native-comp-compiler-options >> + (cond ((featurep 'mps) (list "-fno-omit-frame-pointer"))) >> "Command line options passed verbatim to GCC compiler. > > How about always using -fno-omit-frame-pointer, not as part of a user > option? I agree that would be better. Will come up with a patch once I'm convinced the phantom bug in my MPS build I was chasing for hours is gone. > We could put it in some variable for those few (who?) who might want > to enable -fomit-frame-pointer. I see no reason to expose this to > users, do you? No, it's a mistake to give users the option to compile with -fomit-frame-pointer, IMHO, so let's not do that. > Alternatively, maybe the nativecomp code could be modified not to use > RBP? I'm not sure what you mean: the code is generated by libgccjit. We could try to make all calls to setjmp go through a wrapper which saves %rbp, but that is very difficult because setjmp is not an ordinary function and not treated as one by GCC (bug#46824), so I'd rather not (nevermind the very different API used by windows). Thanks! Pip From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2025 12:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173953670828342 (code B ref 76180); Fri, 14 Feb 2025 12:39:02 +0000 Received: (at 76180) by debbugs.gnu.org; 14 Feb 2025 12:38:28 +0000 Received: from localhost ([127.0.0.1]:47476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiuxg-0007N4-1E for submit@debbugs.gnu.org; Fri, 14 Feb 2025 07:38:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43770) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiuxd-0007Mn-PK for 76180@debbugs.gnu.org; Fri, 14 Feb 2025 07:38:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tiuxW-0006Zg-UK; Fri, 14 Feb 2025 07:38:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=r+aJL1/nzQc+w6Qjwfr5h2jnsbwJM8sau4cJK0irmR0=; b=Ou3cXhksXYvS TwzdCwg9xLrcbjMYMHxz4MqGXOzh3brOU3/Mw7Y/esCj3RK58bNWM2bpgq17zeUPP/N68FZ/FC4jM famxxEYhE77xOlP8C9o9MiZynBNa4/G4ghg6PEMJHliL6E18SUcmzmkfwIl/3WcymAhgSREpBaxv0 /4wHZdhzaUTncKBiJmUcsriynW8BnP90qiRBbh/ZvQcb4va5rDxeBRgegLv3DGzzoCFERjvVx4Tgz k6IPa1Ut4Dh4njX/ZH9a80QWAZZactIDMcZ+lr6D16dBWH8LQrRC5C1a6Zlz8f0i9eXBZhYxz967P E/mbbdpViAZ1SorZlR+MPg==; Date: Fri, 14 Feb 2025 14:38:15 +0200 Message-Id: <86seogg0qw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87jz9sn1xt.fsf@protonmail.com> (message from Pip Cet on Fri, 14 Feb 2025 12:31:15 +0000) References: <8734glomp9.fsf@protonmail.com> <87seokgruy.fsf@protonmail.com> <86wmdvuyj1.fsf@gnu.org> <87jz9sn1xt.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 14 Feb 2025 12:31:15 +0000 > From: Pip Cet > Cc: acorallo@gnu.org, stefankangas@gmail.com, 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, eggert@cs.ucla.edu > > "Eli Zaretskii" writes: > > > Alternatively, maybe the nativecomp code could be modified not to use > > RBP? > > I'm not sure what you mean: the code is generated by libgccjit. Oh, I didn't realize that. If we really have no control over this, then maybe a bug report against libgccjit is in order? From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2025 12:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173953751430921 (code B ref 76180); Fri, 14 Feb 2025 12:52:02 +0000 Received: (at 76180) by debbugs.gnu.org; 14 Feb 2025 12:51:54 +0000 Received: from localhost ([127.0.0.1]:47512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tivAf-00082e-DI for submit@debbugs.gnu.org; Fri, 14 Feb 2025 07:51:54 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:33957) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tivAb-00082M-Gs for 76180@debbugs.gnu.org; Fri, 14 Feb 2025 07:51:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739537502; x=1739796702; bh=kJsIIuzpxoEJz+ginQyO2UI3klODK7SX8OnVEhPXa+o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=LWXMo1p8tXSDUZ12iTS8nOBCwizuOQxtQ//gBcXQ9Cw9T8NI70+gvgf0CsfkGr9KE SYlU5Brxl5VqbKaIyT4IFHyhQVY/ctyd2WzGObKRDKNVyzuH8NTMqDrwFGwHiSV2qm aLuIwd34aNladO3P1DHGATIMxPYvICg1LN42noB4coosfRMI2MXxkLT8qS8FGFarG9 c2c94NqiQ1M6WmJtuEzoLqVe6ndsLCONYXHsBHItIk5Yg0XlsSe9rLKnzhjUqwM864 zyQsLft6vW+ixIqx/CTNgPZQrPWeVszxZThz/cwbazNSiFWsu7JFYMeAOQ9bh4S4mL T7MBfh4dryP2w== Date: Fri, 14 Feb 2025 12:51:37 +0000 From: Pip Cet Message-ID: <87ed00n0zt.fsf@protonmail.com> In-Reply-To: <86y0ybuyr7.fsf@gnu.org> References: <8734glomp9.fsf@protonmail.com> <87msesgrci.fsf@protonmail.com> <86y0ybuyr7.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 14432f5f7d26798ac206a7b0d4da530e1df13a48 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Tue, 11 Feb 2025 20:27:23 +0000 >> From: Pip Cet >> Cc: 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, a= corallo@gnu.org, eggert@cs.ucla.edu, eliz@gnu.org >> >> Pip Cet writes: >> >> > diff --git a/src/lread.c b/src/lread.c >> > index e8cd689d794..67c1bbe5f7b 100644 >> > --- a/src/lread.c >> > +++ b/src/lread.c >> > @@ -3483,6 +3483,11 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp= _Object readcharfun) >> > =09 || NILP (vec[CLOSURE_CONSTANTS])))))) >> > invalid_syntax ("Invalid byte-code object", readcharfun); >> > >> > +#ifdef HAVE_MPS >> > + if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >=3D 1022) >> > + error ("Byte-code object uses too much stack, increase HORRIBLE_E= STIMATE!"); >> > +#endif >> > + >> > if (STRINGP (vec[CLOSURE_CODE])) >> > { >> > if (STRING_MULTIBYTE (vec[CLOSURE_CODE])) >> > -- >> > 2.48.1 >> >> Sorry, this hunk wasn't the one I meant to send. This one needs to be >> applied after it: >> >> diff --git a/src/lread.c b/src/lread.c >> index a638b6eec8e..ae312874574 100644 >> --- a/src/lread.c >> +++ b/src/lread.c >> @@ -3576,7 +3576,7 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Ob= ject readcharfun) >> invalid_syntax ("Invalid byte-code object", readcharfun); >> >> #ifdef HAVE_MPS >> - if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >=3D 1022) >> + if (size > CLOSURE_STACK_DEPTH && XFIXNAT (vec[CLOSURE_STACK_DEPTH]) = >=3D 1022) >> error ("Byte-code object uses too much stack, increase HORRIBLE_EST= IMATE!"); >> #endif >> >> >> to fix the obvious problem :-) > > Can't we figure out how far to scan, instead of using some > more-or-less arbitrary constant? The comments in scan_bc seem to > imply that figuring out the distance to scan should be possible? I've put a lot of debugging statements in, and there are bytecode stacks in excess of 1024 bytes, but they're rare (org mode and cedet, in particular). It also depends on how you build: nativecomp builds seem to have larger bytecode stacks... The problem is that the top of stack is usually kept in a register while exec_byte_code executes, and we don't know which one. However, I don't really understand why struct bc_frame can't be expanded to include the max_stack value when we set up the frame; that way, we'd still be scanning too much in some cases (since max_stack may not be reached), but never too little. We could scan the bytecode stack non-conservatively, but that would require clearing the stack when we build a new frame. However, even if we scan conservatively, it's a lot easier to skip zero words than to look up random words left over from a previous iteration which are most likely no longer valid. I must confess that I've locally changed scan_bc to scan the entire bytecode stack. It may be easier to do that and use memclear when we're popping a frame... Pip From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2025 12:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.173953788531931 (code B ref 76180); Fri, 14 Feb 2025 12:59:02 +0000 Received: (at 76180) by debbugs.gnu.org; 14 Feb 2025 12:58:05 +0000 Received: from localhost ([127.0.0.1]:47520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tivGe-0008Ix-AS for submit@debbugs.gnu.org; Fri, 14 Feb 2025 07:58:04 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:36991) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tivGZ-0008II-HW for 76180@debbugs.gnu.org; Fri, 14 Feb 2025 07:58:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739537872; x=1739797072; bh=7/eHHSrKYxcqKt+a/Y1PnHDrbxpbGsNfiKz89X2pAb8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=a7X9P6TT51OvhGAvdHp7ed16BRAaN2pOBWK+Sqgha0Hvs3HrGjM4gFUno4pJe8T3/ TaW2WqPTcvADANaQ7oIxdDZR2tswKqtgHFOzFiSewkfcW3qQSGT7qxkiXOs/2xg7Gv WO6LWtEQSrKuNXZ3Qj+jZV3h8Ykioy9jXrb48GAtP5Mmm0NJp+joW2ShU4k+S8zQBf zJWWPoBBelOEAX985oIzZ6KWhmjNW32KTx7Epg1lvj6cBM4/0Av7KvwzkuZXqbBqcK ZXLI+sjMjAmufs6FwCZrhsbJEKT3qW6KFs9xcQO6WKFhjtxDiBNOVdiTZmeVai4LVB akwFEe+8a1Pjw== Date: Fri, 14 Feb 2025 12:57:49 +0000 From: Pip Cet Message-ID: <878qq8n0pi.fsf@protonmail.com> In-Reply-To: <86seogg0qw.fsf@gnu.org> References: <8734glomp9.fsf@protonmail.com> <87seokgruy.fsf@protonmail.com> <86wmdvuyj1.fsf@gnu.org> <87jz9sn1xt.fsf@protonmail.com> <86seogg0qw.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cbccec73ee5d7d360dd2912dca317f61df99a402 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Fri, 14 Feb 2025 12:31:15 +0000 >> From: Pip Cet >> Cc: acorallo@gnu.org, stefankangas@gmail.com, 76180@debbugs.gnu.org, ger= d.moellmann@gmail.com, mattiase@acm.org, eggert@cs.ucla.edu >> >> "Eli Zaretskii" writes: >> >> > Alternatively, maybe the nativecomp code could be modified not to use >> > RBP? >> >> I'm not sure what you mean: the code is generated by libgccjit. > > Oh, I didn't realize that. If we really have no control over this, > then maybe a bug report against libgccjit is in order? I think I misexpressed myself. The problem is that libgccjit acts like GCC, generating new native code which may or may not use %rbp depending on the compiler options specified by comp.c. Old versions of libgccjit had no way of passing such compiler options, but current ones do. The question is whether we're happy appending "-fno-omit-frame-pointer", or whether we want to be ambitious and refuse to accept "-fomit-frame-pointer". I haven't tried this, but passing the wrong options to libgccjit might make it assume the wrong ABI or hardware, so causing a crash for a malicious user is probably not something we can avoid; the only question is how we keep bug reports focussed so we don't have to keep this option in mind for every single bug. Pip From unknown Fri Aug 08 19:14:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#76180: [feature/igc] Remaining known tracing issues Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2025 13:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 76180 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: eggert@cs.ucla.edu, 76180@debbugs.gnu.org, mattiase@acm.org, gerd.moellmann@gmail.com, stefankangas@gmail.com, acorallo@gnu.org Received: via spool by 76180-submit@debbugs.gnu.org id=B76180.17395386382134 (code B ref 76180); Fri, 14 Feb 2025 13:11:02 +0000 Received: (at 76180) by debbugs.gnu.org; 14 Feb 2025 13:10:38 +0000 Received: from localhost ([127.0.0.1]:47544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tivSn-0000YJ-1E for submit@debbugs.gnu.org; Fri, 14 Feb 2025 08:10:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55678) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tivSi-0000Wc-6p for 76180@debbugs.gnu.org; Fri, 14 Feb 2025 08:10:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tivSb-00039W-Q7; Fri, 14 Feb 2025 08:10:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WS4vtDaqlBcp3+RSHFP8ieLPLriqdL6UQsn2IaLhHz8=; b=UJtw7LRYtyXd o/F9ebIH6DuodxYmlDqJAXivKtfW12zr2CzfSSvLG1yTxiKp09DtFpYS25cm8QGIhWlmUZcnuvOHK pSVyBTbmHjuSEK3PFGh9HhcqMifDNfJg/uRUogD1L/JZR0gPaTCVnHzieQzwEL8znzQdsEX2qo6jP 9RTkH17LjsWhcPbJ292TNSnOmQj4dpI8ffwu2fcAtOFpzowR/3WhdXJZTgQ0jRkDhxJ+7Bw9yvjhO rlf9N1htMtlTG9D+J8V7geLoIfgPzTT0+e9XGLSdU34eVrOGCMByYSnfDw4rL2nj+B3BZjHrGbf/l CZAZda74qJcLHxvfGq0bhg==; Date: Fri, 14 Feb 2025 15:09:48 +0200 Message-Id: <86r040fzab.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878qq8n0pi.fsf@protonmail.com> (message from Pip Cet on Fri, 14 Feb 2025 12:57:49 +0000) References: <8734glomp9.fsf@protonmail.com> <87seokgruy.fsf@protonmail.com> <86wmdvuyj1.fsf@gnu.org> <87jz9sn1xt.fsf@protonmail.com> <86seogg0qw.fsf@gnu.org> <878qq8n0pi.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 14 Feb 2025 12:57:49 +0000 > From: Pip Cet > Cc: acorallo@gnu.org, stefankangas@gmail.com, 76180@debbugs.gnu.org, gerd.moellmann@gmail.com, mattiase@acm.org, eggert@cs.ucla.edu > > "Eli Zaretskii" writes: > > >> I'm not sure what you mean: the code is generated by libgccjit. > > > > Oh, I didn't realize that. If we really have no control over this, > > then maybe a bug report against libgccjit is in order? > > I think I misexpressed myself. The problem is that libgccjit acts like > GCC, generating new native code which may or may not use %rbp depending > on the compiler options specified by comp.c. Old versions of libgccjit > had no way of passing such compiler options, but current ones do. > > The question is whether we're happy appending "-fno-omit-frame-pointer", > or whether we want to be ambitious and refuse to accept > "-fomit-frame-pointer". I think the former. And maybe not to append that at the very end, so as to leave a "fire escape" for those who, for some reasons, want to use -fomit-frame-pointer, and presumably know what they are doing.