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: Native compilation on MPS branch Date: Wed, 24 Apr 2024 14:14:33 -0400 Message-ID: References: <86wmor6owq.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="17787"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 24 20:15:26 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 1rzh9S-0004QE-6Z for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Apr 2024 20:15:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzh8l-00081C-4o; Wed, 24 Apr 2024 14:14:43 -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 1rzh8d-0007sa-KH for emacs-devel@gnu.org; Wed, 24 Apr 2024 14:14:35 -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 1rzh8d-0005aW-A3; Wed, 24 Apr 2024 14:14:35 -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=bWH2svOnLlPIwRBcjteRLipc8qQnJezHof5pghTqJXc=; b=Pa5wGlrI9Cf0C6kwIu7P HdnTi6yZx+QYpmWo8QFYo2gNHdfFp13damdlxsfikQE3apgykarDUAs4zAeogA0uDKn/7Ju3xDPzt HMGqSpsvF6zx21ijKF2drANy9jEZgx1GoCh80K/Bhk2PqsnQpwi+M9nQSKldtkkn6LXxb9xUOwpkW TIIHnZ+JkSXe2T/l3ow530+6PXO4/JVfE0CUoGvUoEK829VVzx3FJTComFeldG++l9y8z+Hfdr9B0 ew962Ta966kGcS0UhmoNHFdHQI5yM5iq1DxSFuaMetBvLHspdhTEpBjTu5i6sDdYe49VDDixWHGmt yLr1/DrNP3zGXQ==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rzh8b-0001SJ-Uw; Wed, 24 Apr 2024 14:14:33 -0400 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 24 Apr 2024 14:49:59 +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:318041 Archived-At: Gerd M=C3=B6llmann writes: > Andrea Corallo writes: > >> Cool, keep us updated. > > Daily update ;-). :) > Haven't got much further, and can use a little break now. > > I don't know if it makes sense to attach this, but maybe it does... I'm > sometimes keeping notes when debugging (which I find useful when > debugging more than 1 thing at a time). [...] > > The read is in from load_static_obj, which is called from > load_comp_unit. > > #+begin_src c > if (!loading_dump) > { > comp_u->optimize_qualities =3D > load_static_obj (comp_u, TEXT_OPTIM_QLY_SYM); > comp_u->data_vec =3D load_static_obj (comp_u, TEXT_DATA_RELOC_SYM); > comp_u->data_impure_vec =3D > load_static_obj (comp_u, TEXT_DATA_RELOC_IMPURE_SYM); > > if (!NILP (Vpurify_flag)) > /* Non impure can be copied into pure space. */ > comp_u->data_vec =3D Fpurecopy (comp_u->data_vec); > > if (!NILP (Vpurify_flag)) > /* Non impure can be copied into pure space. */ > comp_u->data_vec =3D Fpurecopy (comp_u->data_vec); > #+end_src > > The cu is allocated in MPS, purify is nil > > #+begin_src sh > (lldb) p comp_u > (Lisp_Native_Comp_Unit *) 0x0000000108cc51f0 > (lldb) p is_mps (comp_u) > (bool) true > (lldb) p globals.f_Vpurify_flag > (Lisp_Object) NULL > #+end_src > > Objects are copied > > #+begin_src c > Lisp_Object *data_relocs =3D dynlib_sym (handle, DATA_RELOC_SYM); > Lisp_Object *data_imp_relocs =3D comp_u->data_imp_relocs; > ... > EMACS_INT d_vec_len =3D XFIXNUM (Flength (comp_u->data_vec)); > for (EMACS_INT i =3D 0; i < d_vec_len; i++) > data_relocs[i] =3D AREF (comp_u->data_vec, i); > #+end_src > > data_relocs points somewhere into the loaded dylib, I'd say That's correct > #+begin_src sh > (lldb) p data_relocs > (Lisp_Object *) 0x0000000100ebcfd8 (struct Lisp_Symbol *) $26 =3D 0x000= 0000201af0f48 > (lldb) p is_mps (data_relocs) > (bool) false > (lldb) p pdumper_object_p (data_relocs) > (bool) false > (lldb) p is_pure (data_relocs) > (bool) false > #+end_src > > data_imp_relocs too. Yep > #+begin_src sh > (lldb) p *comp_u > (Lisp_Native_Comp_Unit) { > header =3D (size =3D 4611686018863607815) > file =3D 0x0000000108cc50d4 (struct Lisp_String *) $28 =3D 0x0000000108= cc50d0 > optimize_qualities =3D 0x0000000108cc53bb (struct Lisp_Cons *) $29 =3D = 0x0000000108cc53b8 > lambda_gc_guard_h =3D 0x0000000108cc5255 (struct Lisp_Vector *) $30 =3D= 0x0000000108cc5250 > lambda_c_name_idx_h =3D 0x0000000108cc52ad (struct Lisp_Vector *) $31 = =3D 0x0000000108cc52a8 > data_fdoc_v =3D NULL > data_vec =3D 0x0000000108cd000d (struct Lisp_Vector *) $32 =3D 0x000000= 0108cd0008 > data_impure_vec =3D NULL > data_imp_relocs =3D 0x0000000100ebda00 (struct Lisp_Symbol *) $33 =3D 0= x0000000201af1970 > loaded_once =3D false > load_ongoing =3D true > handle =3D 0x0000000088eb8210 > } > #+end_src > > That all looks like I would have expected. To me as well. > (Note to self: remember register_comp_unit...) > That all happens in (require macroexp) > > Continue. Landing in copy_sequence with invalid string. :/ Dumb question: are you usnug rr to debug this? Thanks Andrea