From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: MPS: native comp Date: Tue, 30 Apr 2024 04:54:47 -0400 Message-ID: References: <86le4wsj14.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26957"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, Helmut Eller To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 30 10:55:47 2024 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 1s1jH9-0006mS-Cc for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Apr 2024 10:55:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1jGG-00025i-L7; Tue, 30 Apr 2024 04:54:52 -0400 Original-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 1s1jGE-00023w-BE for emacs-devel@gnu.org; Tue, 30 Apr 2024 04:54:50 -0400 Original-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 1s1jGE-00080N-1K; Tue, 30 Apr 2024 04:54:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ygK9/BrtMaWzrOzPG0T1edK7z3yibRWdt3XuvVMFtxs=; b=jQ2ZvNyTTe3/Xw9BbnsD bh6PvmhW5IvLKSpGKLRXvvhODdYIn5D7NzAJI83QnZss5dqO87IWmuatlPf8r1p7LWgtzxpRuhrlv 25Gb3El0ojd/MhRBhGGMUXKlvpWVR8F/+Mndgss4MoOCYIS0iYet1RYhekimHPYTqCMyp5uM/Eex+ uxf8clVW0IDFhFVNWLxr1GwGO2Zs82692DKfYT6fE7pQKoZZHv5b4yAUaqXBQUEwT8IqMXi+3HFMt Ny93F/D9sX0SfGXWSumhaJx1PJricRWYsnZaAKCDyEYKpO+3r6H84NtaX5I9ajbWAyr4LYBR1edcu qsNrgOvDPgr/FA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s1jGC-0004rS-Ic; Tue, 30 Apr 2024 04:54:49 -0400 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Tue, 30 Apr 2024 10:08:32 +0200") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318406 Archived-At: Gerd M=C3=B6llmann writes: > Andrea Corallo writes: > >> Gerd M=C3=B6llmann writes: >> >>> Gerd M=C3=B6llmann writes: >>> >>>> That promises to become fun :-/ >>> >>> Sometimes one needs a bit of luck. Another try landed me in an abort in >>> set_internal, and I could see that we have another case of a symbol >>> pointing to a tombstone. So, we have another reference in the >>> compilation unit that we don't trace. >> >> Maybe you can make it more reproducible building at -J1? > > I meanwhile suspect it's ASLR. When I run things under LLDB, ASLR is off > (LLDB does that). When I gmake (with -j1), ASLR on. Yep that makes sense >>> @Andrea: Any intuition where else references could lurk, perhaps? I'm >>> currently doing this: >>> >>> static mps_res_t >>> fix_comp_unit (mps_ss_t ss, struct Lisp_Native_Comp_Unit *u) >>> { >>> MPS_SCAN_BEGIN (ss) >>> { >>> IGC_FIX_CALL_FN (ss, struct Lisp_Vector, u, fix_vectorlike); >>> if (u->data_imp_relocs) >>> { >>> size_t n =3D ASIZE (u->data_impure_vec); >>> IGC_FIX12_NOBJS (ss, u->data_imp_relocs, n); >>> } >>> if (u->data_relocs) >>> { >>> size_t n =3D ASIZE (u->data_vec); >>> IGC_FIX12_NOBJS (ss, u->data_relocs, n); >>> } >>> } >>> MPS_SCAN_END (ss); >>> return MPS_RES_OK; >>> } >>> >>> Maybe there's something wrong with that (the ASIZEs maybe?) >> >> I think the size should be fine, > > Thanks. > >> it would be very interesting to know which one is the symbol that was >> actually killed by the GC. This would give us strong indications. >> Maybe we can use the watchpoint strategy to identify it? > > It's the symbol that leads to the setting-constant error in the eager > macro expansion error. You can see that in the debug org file I attached > to another mail. > > data =3D 0x000000010f0eb008 "byte-compile-form-stack" > > The problem is apparently similar to what we had before: The symbol has > been moved in memory (not freed), and a reference to the symbol was not > updated because we don't trace it. So a watchpoint won't help - the > problem is that nothing changes :-). If the object was moved and the d_reloc is now updated by MPS I've a doubt: What if our object (say d_reloc[x]) is loaded in a register by the compiler? How does the register gets updated by MPS? In native code we do this all the time for performance reasons. > Next strategy or tactic, I think, could be to produce a C file for > macroexp.eln, and see where the symbol appears. I would imagine that I > can deduce from the text representaton of the constants in C what index > correspondons to the symbol, and then see if it is used in surprising > ways. Maybe. WDYT? You'll probably see what I mentioned above. At the beginning of the compiled function we load in regular variables the lisp objects from d_reloc so GCC leverage the register allocater and keep in registers. For instance we do exactly this 'byte-compile-form-stack' and others here: macroexp-1776619e-76691d27.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D extern struct Lisp_X * F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_0 (long long nargs, stru= ct Lisp_X * * args) { struct freloc_link_table * freloc; struct Lisp_X * slot_0; struct Lisp_X * slot_1; struct Lisp_X * slot_2; struct Lisp_X * slot_3; struct Lisp_X * slot_4; struct Lisp_X * slot_5; struct Lisp_X * slot_6; struct comp_handler * c; entry: freloc =3D freloc_link_table; /* Lisp function: nil */ slot_0 =3D *args; /* ptr_arithmetic */ args =3D (struct Lisp_X * *)bitcast((unsigned long long)((unsigned long l= ong)bitcast((void *)args, unsigned long long) + (unsigned long long)8 * (un= signed long long)(long long)1)\ , void *); goto entry_rest_args; entry_rest_args: /* calling subr: list */ slot_1 =3D freloc->R6c697374_list_0 ((nargs - (long long)1), args); goto bb_0; bb_0: /* let */ slot_2 =3D d_reloc[(long long)0]; /* byte-compile-form-stack */ slot_3 =3D d_reloc[(long long)1]; /* cons */ slot_4 =3D d_reloc[(long long)2]; [...] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Where we load it in 'slot_3'. I think the easiest is to to make objects loaded from native code non movable. Is this possible with MPS? What would be the downside of this? They are very rarely collected anyway. WDYT? Thanks Andrea