From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Sat, 28 Dec 2019 15:34:00 +0200 Message-ID: <83png8o9pz.fsf@gnu.org> References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> <83woagonl9.fsf@gnu.org> <83sgl4ojci.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="76461"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 28 14:34:57 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ilCF4-000Jhh-6k for ged-emacs-devel@m.gmane.org; Sat, 28 Dec 2019 14:34:54 +0100 Original-Received: from localhost ([::1]:43456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilCF2-0004sx-9M for ged-emacs-devel@m.gmane.org; Sat, 28 Dec 2019 08:34:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35819) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ilCEG-0004Ni-41 for emacs-devel@gnu.org; Sat, 28 Dec 2019 08:34:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ilCEE-00047s-Fb; Sat, 28 Dec 2019 08:34:02 -0500 Original-Received: from [176.228.60.248] (port=4777 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ilCEA-0007qb-UB; Sat, 28 Dec 2019 08:34:01 -0500 In-reply-to: (message from Andrea Corallo on Sat, 28 Dec 2019 11:57:36 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243731 Archived-At: > From: Andrea Corallo > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Sat, 28 Dec 2019 11:57:36 +0000 > > Every .el file is compiled into a .eln. This is technically a shared > library. > > Into the .eln Emacs is expecting to find a bunch of symbols. Two of > these are used for relocating objects and Emacs primitive functions. So > Emacs essentially writes some pointers into them. Can you tell more about this part? What does this relocation include, and to what extent the details depend on the .eln file being in ELF format? > Then there's 'top_level_run'. This is a real function that is responsible for > modifying the environment as the execution of the various top level forms > on the original .el file would do. > > Emacs jumps into 'top_level_run' and this will call back into Emacs for > evaluating forms and/or defining native functions (effectively new > subrs). This function is obviously not called when resuming from an > image dump. So when Emacs calls a Lisp function foo-bar, that call will produce a call to 'top_level_run' function of the corresponding .eln file, and then 'top_level_run' of that .eln will call the code produced from 'foo-bar'? How does Emacs know which .eln "provides" foo-bar? And how would the code in the .eln know to call back into Emacs? When you compile the native code, do you leave the symbols of Emacs functions unresolved, and rely on the dynamic linker to resolve them? If so, this doesn't work on Windows: you will get link errors. Thanks.