From unknown Mon Aug 18 14:24:59 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#41242 <41242@debbugs.gnu.org> To: bug#41242 <41242@debbugs.gnu.org> Subject: Status: Port feature/native-comp to Windows Reply-To: bug#41242 <41242@debbugs.gnu.org> Date: Mon, 18 Aug 2025 21:24:59 +0000 retitle 41242 Port feature/native-comp to Windows reassign 41242 emacs submitter 41242 Nicolas B=C3=A9rtolo severity 41242 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 15:27:13 2020 Received: (at submit) by debbugs.gnu.org; 13 May 2020 19:27:13 +0000 Received: from localhost ([127.0.0.1]:59607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYx29-0005iH-8t for submit@debbugs.gnu.org; Wed, 13 May 2020 15:27:13 -0400 Received: from lists.gnu.org ([209.51.188.17]:54090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYx28-0005iA-Bc for submit@debbugs.gnu.org; Wed, 13 May 2020 15:27:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYx28-0007Mb-36 for bug-gnu-emacs@gnu.org; Wed, 13 May 2020 15:27:12 -0400 Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]:45235) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jYx26-0000SA-MW for bug-gnu-emacs@gnu.org; Wed, 13 May 2020 15:27:11 -0400 Received: by mail-oi1-x230.google.com with SMTP id d191so2160113oib.12 for ; Wed, 13 May 2020 12:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Tb9Em3nH5dQfk+Ck3goELxai9BWfpHMhI9U9W9nHdFQ=; b=GIBgRJj5UOhvWj1TSz4FJ1VpgDY9i4B2nmZhOOABhT3DEU4pj4HEeE5Vc49Kxr4+LP +AIukNkt8ug6dKxiW/7oIwjKBRDUyfvLVW8Ro/53TnXu84+gCjjaJX+Mec4S6XqYZ60F /aajswqLkDQQWSpBSiIBAEOvGI4KYjuLivp0z8ElN0JKdLLeO+QKTBu73DKGc6sjd0fC wvRonn4xpCTfl9BoHgCPCmrlsIlfDRI0phRHflyHoh3si2Nty6Kc8dsoZ1CDxscjEILV tR6qY7j7zGcpzF8d8FZo+yCB8s2zsjbT/zUQ6IgWqYxjU5RbV7vPv6Phg6HEGijxDaxd h2Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tb9Em3nH5dQfk+Ck3goELxai9BWfpHMhI9U9W9nHdFQ=; b=iyOUBwwwoxyJWPM3sCDzqFHrzRw3UKNaSMX5H5h07/lAgCQ4uoHVqNI1Jlvl2Y2wtS +Lw6IPNQ6Lgoe+e1C93A1aXuwopbXIB/6JdPjc/KKtt1uiycsPSFbRSiGdvwPCHHLCB4 Y4vPz+dogzNE5zU1jOBal5N6csOrFYkQx2/0WNKnNC95Y9WiuEM05I8nHSyer/RKjxZl IdrcV4XYZl1oXmpofJaBKquQc9jIuGwhxgzUivB8nYkPbjx4T9yh1q1JMIRfgHc/WKTr ag4HCbVZ48094NR52IflXsXiS4nYYBRJHqcv+Nw5I3/Lcm4hfwvVkOQRaGnN/T4PF2B7 rA4Q== X-Gm-Message-State: AGi0PuZ8oYj8x1AtZNzr4AiwJN+WcaArCEp4flSaYVzG0mXIZpZsFZ/1 6ZmtVHQKc1xGlHvIeF5kupEF2g1T4gi4idb5/GTv6IE1VKUXHg== X-Google-Smtp-Source: APiQypK86DqFDdraAdUBvmZ4bq3aLRO/WE9/oSAwKAOihVkTK6vAAKyqXWZlAXTMtigeMZxAZeatty+VXK3b2SH2wqQ= X-Received: by 2002:aca:d04:: with SMTP id 4mr7066343oin.120.1589398028790; Wed, 13 May 2020 12:27:08 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 13 May 2020 16:26:57 -0300 Message-ID: Subject: Port feature/native-comp to Windows To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000e9dc2405a58c90b2" Received-SPF: pass client-ip=2607:f8b0:4864:20::230; envelope-from=nicolasbertolo@gmail.com; helo=mail-oi1-x230.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit 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: -2.3 (--) --000000000000e9dc2405a58c90b2 Content-Type: text/plain; charset="UTF-8" The attached patches contain changes to make the feature/native-comp branch work on Windows. There are a few remaining issues: * The loading process is very slow. This is especially annoying when coupled with autoloading. For example, autoloading Helm may stall Emacs for 5 seconds in my machine. I have thought a possible solution to this problem: load the byte-compiled file and put the native-compiled version in a list. Then load that list one by one on an idle-timer, that way the UI freezes should be minimized. This could reuse the "late loading" machinery implemented for deferred compilation. * `package-delete` fails because it tries to delete the .eln file via `delete-file`. This is impossible in Windows because it's generally impossible to delete files that have an open HANDLE in the system. Three solutions have crossed my mind: - Edit `package-delete` to put the eln on a list of files that should be deleted when Emacs is closed. - Implement an unloading mechanism for native-compiled files. - Copy eln files to temporary files and load those temporary files instead. This means that deleting the original eln file is possible. I'd prefer the second option, but I have a semi-working patch for the third option. * The `emacs_dir` environment variable needs to be set when loading the dump file. It is necessary for `expand-file-name`, which calls emacs_root_dir(). I haven't investigated why this is necessary yet. One workaround would be to use GetModuleFileName() to get the path to emacs.exe when `emacs_dir` is not set. --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0001-HACK-Ensure-the-emacs_root_dir-function-does-not-cra.patch" Content-Disposition: attachment; filename="0001-HACK-Ensure-the-emacs_root_dir-function-does-not-cra.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjddn0 RnJvbSA2OGFkMTBkYTlmZjUzOGFiMjFkYTFhNGY0MGVlNGI1NTZkNmEzZDc2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE2OjMw OjExIC0wMzAwClN1YmplY3Q6IFtQQVRDSCAxLzhdIEhBQ0s6IEVuc3VyZSB0aGUgYGVtYWNzX3Jv b3RfZGlyYCBmdW5jdGlvbiBkb2VzIG5vdAogY3Jhc2guCgpUaGF0IGZ1bmN0aW9uIGlzIGNhbGxl ZCB3aGVuIGNhbGxpbmcgYGxvYWRfcGR1bXBgLiBUaGUgcHJvYmxlbSBpcyB0aGF0CnRoYXQgaGFw cGVucyB0b28gZWFybHkgaW4gdGhlIGluaXRpYWxpemF0aW9uIHByb2Nlc3MgYW5kIHRoZQpgZW1h Y3NfZGlyYCBlbnZpcm9ubWVudCB2YXJpYWJsZSB3aWxsIG5vdCBoYXZlIGJlZW4gaW5pdGlhbGl6 ZWQgeWV0LgoKVGhlIHByb3BlciBmaXggd291bGQgYmUgdG8gaW5pdGlhbGl6ZSBgZW1hY3NfZGly YCBlYXJseSBlbm91Z2guIEkgZG8Kbm90IGtub3cgZW5vdWdoIG9mIHRoZSBFbWFjcyBpbnRlcm5h bHMgdG8gZG8gdGhhdCBzYWZlbHkuCi0tLQogc3JjL3czMi5jIHwgMiArLQogMSBmaWxlIGNoYW5n ZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL3czMi5j IGIvc3JjL3czMi5jCmluZGV4IDBmNjllNjUyYTUuLmE4Yzc2M2YyM2UgMTAwNjQ0Ci0tLSBhL3Ny Yy93MzIuYworKysgYi9zcmMvdzMyLmMKQEAgLTMxNTQsNyArMzE1NCw3IEBAIGVtYWNzX3Jvb3Rf ZGlyICh2b2lkKQogCiAgIHAgPSBnZXRlbnYgKCJlbWFjc19kaXIiKTsKICAgaWYgKHAgPT0gTlVM TCkKLSAgICBlbWFjc19hYm9ydCAoKTsKKyAgICBwID0gIkM6L1VzZXJzIjsKICAgZmlsZW5hbWVf ZnJvbV9hbnNpIChwLCByb290X2Rpcik7CiAgIHJvb3RfZGlyW3BhcnNlX3Jvb3QgKHJvb3RfZGly LCBOVUxMKV0gPSAnXDAnOwogICBkb3N0b3VuaXhfZmlsZW5hbWUgKHJvb3RfZGlyKTsKLS0gCjIu MjUuMS53aW5kb3dzLjEKCg== --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0002-Do-not-block-SIGIO-in-platforms-that-don-t-have-it.patch" Content-Disposition: attachment; filename="0002-Do-not-block-SIGIO-in-platforms-that-don-t-have-it.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjde91 RnJvbSAxY2U3ZmU5ZDJmYTY2YmJjZTQ1NTIzYjYyNzUwNzFjYWQ2ODUzMjQ4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE2OjAy OjU4IC0wMzAwClN1YmplY3Q6IFtQQVRDSCAyLzhdIERvIG5vdCBibG9jayBTSUdJTyBpbiBwbGF0 Zm9ybXMgdGhhdCBkb24ndCBoYXZlIGl0LgoKKiBzcmMvY29tcC5jIChjb21wLS1jb21waWxlLWN0 eHQtdG8tZmlsZSk6IEFkZCBhIHByZXByb2Nlc3NvciBjaGVjayB0bwphdm9pZCBibG9ja2luZyBT SUdJTyBpbiBwbGF0Zm9ybXMgdGhhdCBkb24ndCBoYXZlIGl0LgotLS0KIHNyYy9jb21wLmMgfCAy ICsrCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Nv bXAuYyBiL3NyYy9jb21wLmMKaW5kZXggZTNhODBhZGZhOS4uMDBmOWQ0Yjc0YSAxMDA2NDQKLS0t IGEvc3JjL2NvbXAuYworKysgYi9zcmMvY29tcC5jCkBAIC0zMzQ1LDcgKzMzNDUsOSBAQCBERUZV TiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBfX2NvbXBpbGVfY3R4dF90b19m aWxlLAogICAgICAgc2lnZW1wdHlzZXQgKCZibG9ja2VkKTsKICAgICAgIHNpZ2FkZHNldCAoJmJs b2NrZWQsIFNJR0FMUk0pOwogICAgICAgc2lnYWRkc2V0ICgmYmxvY2tlZCwgU0lHSU5UKTsKKyNp ZmRlZiBVU0FCTEVfU0lHSU8KICAgICAgIHNpZ2FkZHNldCAoJmJsb2NrZWQsIFNJR0lPKTsKKyNl bmRpZgogICAgICAgcHRocmVhZF9zaWdtYXNrIChTSUdfQkxPQ0ssICZibG9ja2VkLCAmb2xkc2V0 KTsKICAgICB9CiAgIGVtaXRfY3R4dF9jb2RlICgpOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0003-Handle-setjmp-taking-two-arguments-in-Windows.patch" Content-Disposition: attachment; filename="0003-Handle-setjmp-taking-two-arguments-in-Windows.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdeq2 RnJvbSA4ZWE1Y2VkYTYzODljMjI3ZjgyZThkNjk4YjY0NDM0NGYxN2Y1MmI5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE1OjU2 OjA5IC0wMzAwClN1YmplY3Q6IFtQQVRDSCAzLzhdIEhhbmRsZSBzZXRqbXAoKSB0YWtpbmcgdHdv IGFyZ3VtZW50cyBpbiBXaW5kb3dzLgoKKiBzcmMvY29tcC5jOiBBZGQgYGRlZmluZV9zZXRqbXBf ZGVwcygpYCBhbmQgYGVtaXRfc2V0am1wKClgIHdoaWNoCmFic3RyYWN0IG92ZXIgdGhpcyBkaWZm ZXJlbmNlIGluIGJlaGF2aW9yIGJldHdlZW4gb3BlcmF0aW5nIHN5c3RlbXMuCgpXQVJOSU5HOiBO b3QgYWxsIGNhc2VzIGFyZSBoYW5kbGVkIGJ5IHRoaXMgcGF0Y2guIFRoZSBNaW5ndy02NApzZXRq bXAuaCBoZWFkZXIgZGVhbHMgd2l0aCBtYW55IG90aGVyIGNvbWJpbmF0aW9ucy4gSSBkb24ndCB0 aGluayBpdAppcyBhIGdvb2QgaWRlYSB0byByZXBsaWNhdGUgdGhlIGxvZ2ljIG9mIHRoYXQgaGVh ZGVyIGluc2lkZQplbWFjcy4gKE1heWJlIGEgZmV3IGxpbmVzIGluIHRoZSBjb25maWd1cmUgc2Ny aXB0IGNvdWxkIGJlIGFkZGVkIHRvCmhhbmRsZSB0aGlzIHByb2JsZW0/KQotLS0KIHNyYy9jb21w LmMgfCA1OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKyst LS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA1MiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoK ZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29tcC5jCmluZGV4IDAwZjlkNGI3NGEuLjBk NDY2MjhlNmEgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMKKysrIGIvc3JjL2NvbXAuYwpAQCAtMjIs NiArMjIsNyBAQAogCiAjaWZkZWYgSEFWRV9OQVRJVkVfQ09NUAogCisjaW5jbHVkZSA8c2V0am1w Lmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxz aWduYWwuaD4KQEAgLTc0LDEwICs3NSwxNSBAQCAjZGVmaW5lIERFQ0xfQkxPQ0sobmFtZSwgZnVu YykJCQkJXAogICBnY2Nfaml0X2Jsb2NrICoobmFtZSkgPQkJCQlcCiAgICAgZ2NjX2ppdF9mdW5j dGlvbl9uZXdfYmxvY2sgKChmdW5jKSwgU1RSIChuYW1lKSkKIAotI2lmZGVmIEhBVkVfX1NFVEpN UAotI2RlZmluZSBTRVRKTVAgX3NldGptcAorI2lmbmRlZiBfV0lOMzIKKyMgaWZkZWYgSEFWRV9f U0VUSk1QCisjICBkZWZpbmUgU0VUSk1QIF9zZXRqbXAKKyMgZWxzZQorIyAgZGVmaW5lIFNFVEpN UCBzZXRqbXAKKyMgZW5kaWYKICNlbHNlCi0jZGVmaW5lIFNFVEpNUCBzZXRqbXAKKy8qIHNuaXBw ZXQgZnJvbSBNSU5HVy02NCBzZXRqbXAuaCAqLworIyBkZWZpbmUgU0VUSk1QIF9zZXRqbXAKICNl bmRpZgogI2RlZmluZSBTRVRKTVBfTkFNRSBTRVRKTVAKIApAQCAtMTc0LDYgKzE4MCw5IEBAICNk ZWZpbmUgRl9SRUxPQ19NQVhfU0laRSAxNTAwCiAgIGdjY19qaXRfZnVuY3Rpb24gKnNldGNkcjsK ICAgZ2NjX2ppdF9mdW5jdGlvbiAqY2hlY2tfdHlwZTsKICAgZ2NjX2ppdF9mdW5jdGlvbiAqY2hl Y2tfaW1wdXJlOworI2lmZGVmIF9XSU4zMgorICBnY2Nfaml0X2Z1bmN0aW9uICpzZXRqbXBfY3R4 X2Z1bmM7CisjZW5kaWYKICAgTGlzcF9PYmplY3QgZnVuY19ibG9ja3NfaDsgLyogYmxrX25hbWUg LT4gZ2NjX2Jsb2NrLiAgKi8KICAgTGlzcF9PYmplY3QgZXhwb3J0ZWRfZnVuY3NfaDsgLyogYy1m dW5jLW5hbWUgLT4gZ2NjX2ppdF9mdW5jdGlvbiAqLiAgKi8KICAgTGlzcF9PYmplY3QgaW1wb3J0 ZWRfZnVuY3NfaDsgLyogc3Vicl9uYW1lIC0+IGdjY19qaXRfZmllbGQgKnJlbG9jX2ZpZWxkLiAg Ki8KQEAgLTE0NzQsNiArMTQ4MywyOSBAQCBlbWl0X2xpbXBsZV9jYWxsX3JlZiAoTGlzcF9PYmpl Y3QgaW5zbiwgYm9vbCBkaXJlY3QpCiAJCQlkaXJlY3QpOwogfQogCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9zZXRqbXAgKGdjY19qaXRfcnZhbHVlICpidWYpCit7CisjaWZuZGVmIF9X SU4zMgorICBnY2Nfaml0X3J2YWx1ZSAqYXJnc1tdID0ge2J1Zn07CisgIHJldHVybiBlbWl0X2Nh bGwgKGludGVybl9jX3N0cmluZyAoU1RSIChTRVRKTVBfTkFNRSkpLCBjb21wLmludF90eXBlLCAx LCBhcmdzLAorICAgICAgICAgICAgICAgICAgIGZhbHNlKTsKKyNlbHNlCisgIC8qIF9zZXRqbXAg KGJ1ZiwgX19idWlsdGluX2ZyYW1lX2FkZHJlc3MgKDApKSAqLworICBnY2Nfaml0X3J2YWx1ZSAq YXJnc1syXTsKKworICBhcmdzWzBdID0gZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9p bnQgKGNvbXAuY3R4dCwgY29tcC51bnNpZ25lZF90eXBlLCAwKTsKKworICBhcmdzWzFdID0gZ2Nj X2ppdF9jb250ZXh0X25ld19jYWxsKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbXAuc2V0am1wX2N0eF9mdW5jLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDEsIGFyZ3MpOworICBhcmdzWzBdID0gYnVmOworICByZXR1cm4gZW1pdF9jYWxsIChpbnRl cm5fY19zdHJpbmcgKFNUUiAoU0VUSk1QX05BTUUpKSwgY29tcC5pbnRfdHlwZSwgMiwgYXJncywK KyAgICAgICAgICAgICAgICAgICAgZmFsc2UpOworI2VuZGlmCit9CisKIC8qIFJlZ2lzdGVyIGFu IGhhbmRsZXIgZm9yIGEgbm9uIGxvY2FsIGV4aXQuICAqLwogCiBzdGF0aWMgdm9pZApAQCAtMTUw MCw4ICsxNTMyLDcgQEAgZW1pdF9saW1wbGVfcHVzaF9oYW5kbGVyIChnY2Nfaml0X3J2YWx1ZSAq aGFuZGxlciwgZ2NjX2ppdF9ydmFsdWUgKmhhbmRsZXJfdHlwZSwKIAlOVUxMKTsKIAogICBnY2Nf aml0X3J2YWx1ZSAqcmVzOwotICByZXMgPQotICAgIGVtaXRfY2FsbCAoaW50ZXJuX2Nfc3RyaW5n IChTVFIgKFNFVEpNUF9OQU1FKSksIGNvbXAuaW50X3R5cGUsIDEsIGFyZ3MsIGZhbHNlKTsKKyAg cmVzID0gZW1pdF9zZXRqbXAoYXJnc1swXSk7CiAgIGVtaXRfY29uZF9qdW1wIChyZXMsIGhhbmRs ZXJfYmIsIGd1YXJkZWRfYmIpOwogfQogCkBAIC0yMDYwLDggKzIwOTEsMTQgQEAgI2RlZmluZSBB RERfSU1QT1JURUQoZl9uYW1lLCByZXRfdHlwZSwgbmFyZ3MsIGFyZ3MpCQkJICAgICAgIFwKICAg YXJnc1sxXSA9IGNvbXAuaW50X3R5cGU7CiAgIEFERF9JTVBPUlRFRCAocHVzaF9oYW5kbGVyLCBj b21wLmhhbmRsZXJfcHRyX3R5cGUsIDIsIGFyZ3MpOwogCisjaWZuZGVmIF9XSU4zMgogICBhcmdz WzBdID0gZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyIChnY2Nfaml0X3N0cnVjdF9hc190eXBlIChj b21wLmptcF9idWZfcykpOwogICBBRERfSU1QT1JURUQgKFNFVEpNUF9OQU1FLCBjb21wLmludF90 eXBlLCAxLCBhcmdzKTsKKyNlbHNlCisgIGFyZ3NbMF0gPSBnY2Nfaml0X3R5cGVfZ2V0X3BvaW50 ZXIgKGdjY19qaXRfc3RydWN0X2FzX3R5cGUgKGNvbXAuam1wX2J1Zl9zKSk7CisgIGFyZ3NbMV0g PSBjb21wLnZvaWRfcHRyX3R5cGU7CisgIEFERF9JTVBPUlRFRCAoU0VUSk1QX05BTUUsIGNvbXAu aW50X3R5cGUsIDIsIGFyZ3MpOworI2VuZGlmCiAKICAgQUREX0lNUE9SVEVEIChyZWNvcmRfdW53 aW5kX3Byb3RlY3RfZXhjdXJzaW9uLCBjb21wLnZvaWRfdHlwZSwgMCwgTlVMTCk7CiAKQEAgLTIz MDEsNyArMjMzOCw3IEBAIGRlZmluZV9qbXBfYnVmICh2b2lkKQogICAgICAgZ2NjX2ppdF9jb250 ZXh0X25ld19hcnJheV90eXBlIChjb21wLmN0eHQsCiAJCQkJICAgICAgTlVMTCwKIAkJCQkgICAg ICBjb21wLmNoYXJfdHlwZSwKLQkJCQkgICAgICBzaXplb2YgKGptcF9idWYpKSwKKwkJCQkgICAg ICBzaXplb2YgKHN5c19qbXBfYnVmKSksCiAgICAgICAic3R1ZmYiKTsKICAgY29tcC5qbXBfYnVm X3MgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfc3RydWN0X3R5cGUgKGNvbXAuY3R4dCwKQEAg LTI5NjksNiArMzAwNiwxNCBAQCBkZWZpbmVfQ0hFQ0tfSU1QVVJFICh2b2lkKQogICAgIGdjY19q aXRfYmxvY2tfZW5kX3dpdGhfdm9pZF9yZXR1cm4gKGVycl9ibG9jaywgTlVMTCk7CiB9CiAKK3N0 YXRpYyB2b2lkCitkZWZpbmVfc2V0am1wX2RlcHMgKHZvaWQpCit7CisgIGNvbXAuc2V0am1wX2N0 eF9mdW5jCisgICAgPSBnY2Nfaml0X2NvbnRleHRfZ2V0X2J1aWx0aW5fZnVuY3Rpb24gKGNvbXAu Y3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIl9fYnVp bHRpbl9mcmFtZV9hZGRyZXNzIik7Cit9CisKIC8qIERlZmluZSBhIGZ1bmN0aW9uIHRvIGNvbnZl cnQgYm9vbGVhbiBpbnRvIHQgb3IgbmlsICovCiAKIHN0YXRpYyB2b2lkCkBAIC0zMzU3LDYgKzM0 MDIsNyBAQCBERUZVTiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBfX2NvbXBp bGVfY3R4dF90b19maWxlLAogICBkZWZpbmVfUFNFVURPVkVDVE9SUCAoKTsKICAgZGVmaW5lX0NI RUNLX1RZUEUgKCk7CiAgIGRlZmluZV9DSEVDS19JTVBVUkUgKCk7CisgIGRlZmluZV9zZXRqbXBf ZGVwcyAoKTsKICAgZGVmaW5lX2Jvb2xfdG9fbGlzcF9vYmogKCk7CiAgIGRlZmluZV9zZXRjYXJf c2V0Y2RyICgpOwogICBkZWZpbmVfYWRkMV9zdWIxICgpOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch" Content-Disposition: attachment; filename="0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdey3 RnJvbSA1YjhkNTI5YmFhOGIzYzUxYTkyMjBhYTE0OTM2MmMyZDdjNWZhMTYwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE0OjMw OjE0IC0wMzAwClN1YmplY3Q6IFtQQVRDSCA0LzhdIEhhbmRsZSBMSVNQX1dPUkRTX0FSRV9QT0lO VEVSUyBhbmQKIENIRUNLX0xJU1BfT0JKRUNUX1RZUEUuCgoqIHNyYy9jb21wLmM6IEludHJvZHVj ZSB0aGUgTGlzcF9YLCBMaXNwX1dvcmQsIGFuZCBMaXNwX1dvcmRfdGFnCnR5cGVzLiBUaGVzZSB0 eXBlcyBhcmUgdXNlZCBpbnN0ZWFkIG9mIGxvbmcgb3IgbG9uZyBsb25nLiBVc2UKZW1hY3NfaW50 X3R5cGUgYW5kIGVtYWNzX3VpbnRfdHlwZXMgd2hlcmUgYXBwcm9wcmlhdGUuCihlbWl0X2NvZXJj ZSk6IEFkZCBzcGVjaWFsIGxvZ2ljIHRoYXQgaGFuZGxlcyB0aGUgY2FzZSB3aGVuCkxpc3BfT2Jq ZWN0IGlzIGEgc3RydWN0LiBUaGlzIGlzIG5lY2Vzc2FyeSBmb3IgaGFuZGxpbmcgdGhlCi0tZW5h YmxlLWNoZWNrLWxpc3Atb2JqZWN0LXR5cGUgY29uZmlndXJlIG9wdGlvbi4KCiogc3JjL2xpc3Au aDogU2luY2UgbGliZ2Njaml0IGRvZXMgbm90IHN1cHBvcnQgb3BhcXVlIHVuaW9ucywgY2hhbmdl Ckxpc3BfWCB0byBiZSBzdHJ1Y3QuIFRoaXMgaXMgZG9uZSB0byBlbnN1cmUgdGhhdCB0aGUgc2Ft ZSB0eXBlcyBhcmUKdXNlZCBpbiB0aGUgc2FtZSBiaW5hcnkuIEl0IGlzIHByb2JhYmx5IHVubmVj ZXNzYXJ5IHNpbmNlIG9ubHkgYQpwb2ludGVyIHRvIGl0IGlzIHVzZWQuCi0tLQogc3JjL2NvbXAu YyB8IDMyOCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t LS0tLQogc3JjL2xpc3AuaCB8ICAgNSArLQogMiBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9u cygrKSwgMTA1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29t cC5jCmluZGV4IDBkNDY2MjhlNmEuLjBkNTg4MGFkM2MgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMK KysrIGIvc3JjL2NvbXAuYwpAQCAtMTE2LDYgKzExNiwxNiBAQCAjZGVmaW5lIEZfUkVMT0NfTUFY X1NJWkUgMTUwMAogICBnY2Nfaml0X3R5cGUgKmNoYXJfcHRyX3R5cGU7CiAgIGdjY19qaXRfdHlw ZSAqcHRyZGlmZl90eXBlOwogICBnY2Nfaml0X3R5cGUgKnVpbnRwdHJfdHlwZTsKKyNpZiBMSVNQ X1dPUkRTX0FSRV9QT0lOVEVSUworICBnY2Nfaml0X3N0cnVjdCAqbGlzcF9YX3M7CisgIGdjY19q aXRfdHlwZSAqbGlzcF9YOworI2VuZGlmCisgIGdjY19qaXRfdHlwZSAqbGlzcF93b3JkX3R5cGU7 CisgIGdjY19qaXRfdHlwZSAqbGlzcF93b3JkX3RhZ190eXBlOworI2lmZGVmIExJU1BfT0JKRUNU X0lTX1NUUlVDVAorICBnY2Nfaml0X2ZpZWxkICpsaXNwX29ial9pOworICBnY2Nfaml0X3N0cnVj dCAqbGlzcF9vYmpfczsKKyNlbmRpZgogICBnY2Nfaml0X3R5cGUgKmxpc3Bfb2JqX3R5cGU7CiAg IGdjY19qaXRfdHlwZSAqbGlzcF9vYmpfcHRyX3R5cGU7CiAgIC8qIHN0cnVjdCBMaXNwX0NvbnMg Ki8KQEAgLTE1OCw3ICsxNjgsOCBAQCAjZGVmaW5lIEZfUkVMT0NfTUFYX1NJWkUgMTUwMAogICBn Y2Nfaml0X2ZpZWxkICpjYXN0X3VuaW9uX2FzX2NfcDsKICAgZ2NjX2ppdF9maWVsZCAqY2FzdF91 bmlvbl9hc192X3A7CiAgIGdjY19qaXRfZmllbGQgKmNhc3RfdW5pb25fYXNfbGlzcF9jb25zX3B0 cjsKLSAgZ2NjX2ppdF9maWVsZCAqY2FzdF91bmlvbl9hc19saXNwX29iajsKKyAgZ2NjX2ppdF9m aWVsZCAqY2FzdF91bmlvbl9hc19saXNwX3dvcmQ7CisgIGdjY19qaXRfZmllbGQgKmNhc3RfdW5p b25fYXNfbGlzcF93b3JkX3RhZzsKICAgZ2NjX2ppdF9maWVsZCAqY2FzdF91bmlvbl9hc19saXNw X29ial9wdHI7CiAgIGdjY19qaXRfZnVuY3Rpb24gKmZ1bmM7IC8qIEN1cnJlbnQgZnVuY3Rpb24g YmVpbmcgY29tcGlsZWQuICAqLwogICBib29sIGZ1bmNfaGFzX25vbl9sb2NhbDsgLyogRnJvbSBj b21wLWZ1bmMgaGFzLW5vbi1sb2NhbCBzbG90LiAgKi8KQEAgLTM0Nyw4ICszNTgsMTAgQEAgdHlw ZV90b19jYXN0X2ZpZWxkIChnY2Nfaml0X3R5cGUgKnR5cGUpCiAgICAgZmllbGQgPSBjb21wLmNh c3RfdW5pb25fYXNfY19wOwogICBlbHNlIGlmICh0eXBlID09IGNvbXAubGlzcF9jb25zX3B0cl90 eXBlKQogICAgIGZpZWxkID0gY29tcC5jYXN0X3VuaW9uX2FzX2xpc3BfY29uc19wdHI7Ci0gIGVs c2UgaWYgKHR5cGUgPT0gY29tcC5saXNwX29ial90eXBlKQotICAgIGZpZWxkID0gY29tcC5jYXN0 X3VuaW9uX2FzX2xpc3Bfb2JqOworICBlbHNlIGlmICh0eXBlID09IGNvbXAubGlzcF93b3JkX3R5 cGUpCisgICAgZmllbGQgPSBjb21wLmNhc3RfdW5pb25fYXNfbGlzcF93b3JkOworICBlbHNlIGlm ICh0eXBlID09IGNvbXAubGlzcF93b3JkX3RhZ190eXBlKQorICAgIGZpZWxkID0gY29tcC5jYXN0 X3VuaW9uX2FzX2xpc3Bfd29yZF90YWc7CiAgIGVsc2UgaWYgKHR5cGUgPT0gY29tcC5saXNwX29i al9wdHJfdHlwZSkKICAgICBmaWVsZCA9IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29ial9wdHI7 CiAgIGVsc2UKQEAgLTYyNyw2ICs2NDAsMzEgQEAgZW1pdF9jb2VyY2UgKGdjY19qaXRfdHlwZSAq bmV3X3R5cGUsIGdjY19qaXRfcnZhbHVlICpvYmopCiAgIGlmIChuZXdfdHlwZSA9PSBvbGRfdHlw ZSkKICAgICByZXR1cm4gb2JqOwogCisjaWZkZWYgTElTUF9PQkpFQ1RfSVNfU1RSVUNUCisgIGlm IChvbGRfdHlwZSA9PSBjb21wLmxpc3Bfb2JqX3R5cGUpCisgICAgeworICAgICAgZ2NjX2ppdF9y dmFsdWUgKmx3b3Jkb2JqID0KKyAgICAgICAgZ2NjX2ppdF9ydmFsdWVfYWNjZXNzX2ZpZWxkIChv YmosIE5VTEwsIGNvbXAubGlzcF9vYmpfaSk7CisgICAgICByZXR1cm4gZW1pdF9jb2VyY2UgKG5l d190eXBlLCBsd29yZG9iaik7CisgICAgfQorCisgIGlmIChuZXdfdHlwZSA9PSBjb21wLmxpc3Bf b2JqX3R5cGUpCisgICAgeworICAgICAgZ2NjX2ppdF9ydmFsdWUgKmx3b3Jkb2JqID0KKyAgICAg ICAgZW1pdF9jb2VyY2UgKGNvbXAubGlzcF93b3JkX3R5cGUsIG9iaik7CisKKyAgICAgIGdjY19q aXRfbHZhbHVlICp0bXBfcworICAgICAgICA9IGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsIChj b21wLmZ1bmMsIE5VTEwsIGNvbXAubGlzcF9vYmpfdHlwZSwKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9ybWF0X3N0cmluZyAoImxpc3Bfb2JqXyV0ZCIsIGkrKykpOwor CisgICAgICBnY2Nfaml0X2Jsb2NrX2FkZF9hc3NpZ25tZW50IChjb21wLmJsb2NrLCBOVUxMLAor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2NjX2ppdF9sdmFsdWVfYWNjZXNz X2ZpZWxkICh0bXBfcywgTlVMTCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX29ial9pKSwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGx3b3Jkb2JqKTsKKyAgICAgIHJldHVybiBnY2Nf aml0X2x2YWx1ZV9hc19ydmFsdWUgKHRtcF9zKTsKKyAgICB9CisjZW5kaWYKKwogICBnY2Nfaml0 X2ZpZWxkICpvcmlnX2ZpZWxkID0KICAgICB0eXBlX3RvX2Nhc3RfZmllbGQgKG9sZF90eXBlKTsK ICAgZ2NjX2ppdF9maWVsZCAqZGVzdF9maWVsZCA9IHR5cGVfdG9fY2FzdF9maWVsZCAobmV3X3R5 cGUpOwpAQCAtNjY0LDE0ICs3MDIsOCBAQCBlbWl0X2JpbmFyeV9vcCAoZW51bSBnY2Nfaml0X2Jp bmFyeV9vcCBvcCwKIC8qIFNob3VsZCBjb21lIHdpdGggbGliZ2Njaml0LiAgKi8KIAogc3RhdGlj IGdjY19qaXRfcnZhbHVlICoKLWVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChsb25nIGxvbmcg bikKK2VtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChnY2Nfaml0X3R5cGUgKnR5cGUsIGxvbmcg bG9uZyBuKQogewotI2lmbmRlZiBXSURFX0VNQUNTX0lOVAotICB4c2lnbmFsMSAoUW5hdGl2ZV9p Y2UsCi0JICAgIGJ1aWxkX3N0cmluZyAoImVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIGNhbGxl ZCBpbiBub24gd2lkZSBpbnQiCi0JCQkgICIgY29uZmlndXJhdGlvbiIpKTsKLSNlbmRpZgotCiAg IGVtaXRfY29tbWVudCAoZm9ybWF0X3N0cmluZyAoImVtaXQgbG9uZyBsb25nOiAlbGxkIiwgbikp OwogCiAgIGdjY19qaXRfcnZhbHVlICpoaWdoID0KQEAgLTY5Nyw3ICs3MjksNyBAQCBlbWl0X3J2 YWx1ZV9mcm9tX2xvbmdfbG9uZyAobG9uZyBsb25nIG4pCiAJCSAgICAgIDMyKSk7CiAKICAgcmV0 dXJuCi0gICAgZW1pdF9jb2VyY2UgKGNvbXAubG9uZ19sb25nX3R5cGUsCisgICAgZW1pdF9jb2Vy Y2UgKHR5cGUsCiAgICAgICBlbWl0X2JpbmFyeV9vcCAoCiAJR0NDX0pJVF9CSU5BUllfT1BfQklU V0lTRV9PUiwKIAljb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLApAQCAtNzEyLDI5ICs3NDQs MTM1IEBAIGVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChsb25nIGxvbmcgbikKIH0KIAogc3Rh dGljIGdjY19qaXRfcnZhbHVlICoKLWVtaXRfbW9zdF9wb3NpdGl2ZV9maXhudW0gKHZvaWQpCitl bWl0X3J2YWx1ZV9mcm9tX3Vuc2lnbmVkX2xvbmdfbG9uZyAoZ2NjX2ppdF90eXBlICp0eXBlLCB1 bnNpZ25lZCBsb25nIGxvbmcgbikKK3sKKyAgZW1pdF9jb21tZW50IChmb3JtYXRfc3RyaW5nICgi ZW1pdCB1bnNpZ25lZCBsb25nIGxvbmc6ICVsbHUiLCBuKSk7CisKKyAgZ2NjX2ppdF9ydmFsdWUg KmhpZ2ggPQorICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9uZyAoY29tcC5j dHh0LAorCQkJCQkgIGNvbXAudW5zaWduZWRfbG9uZ19sb25nX3R5cGUsCisJCQkJCSAgbiA+PiAz Mik7CisgIGdjY19qaXRfcnZhbHVlICpsb3cgPQorICAgIGVtaXRfYmluYXJ5X29wIChHQ0NfSklU X0JJTkFSWV9PUF9SU0hJRlQsCisJCSAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAor CQkgICAgZW1pdF9iaW5hcnlfb3AgKEdDQ19KSVRfQklOQVJZX09QX0xTSElGVCwKKwkJCQkgICAg Y29tcC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJCQkgICAgZ2NjX2ppdF9jb250ZXh0X25l d19ydmFsdWVfZnJvbV9sb25nICgKKwkJCQkgICAgICBjb21wLmN0eHQsCisJCQkJICAgICAgY29t cC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJCQkgICAgICBuKSwKKwkJCQkgICAgZ2NjX2pp dF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKAorCQkJCSAgICAgIGNvbXAuY3R4dCwKKwkJ CQkgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorCQkJCSAgICAgIDMyKSksCisJ CSAgICBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCAoCisJCSAgICAgIGNvbXAu Y3R4dCwKKwkJICAgICAgY29tcC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJICAgICAgMzIp KTsKKworICByZXR1cm4gZW1pdF9jb2VyY2UgKAorICAgICAgICAgICB0eXBlLAorICAgICAgICAg ICBlbWl0X2JpbmFyeV9vcCAoCisgICAgICAgICAgICAgR0NDX0pJVF9CSU5BUllfT1BfQklUV0lT RV9PUiwKKyAgICAgICAgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorICAgICAg ICAgICAgIGVtaXRfYmluYXJ5X29wICgKKyAgICAgICAgICAgICAgIEdDQ19KSVRfQklOQVJZX09Q X0xTSElGVCwKKyAgICAgICAgICAgICAgIGNvbXAudW5zaWduZWRfbG9uZ19sb25nX3R5cGUsCisg ICAgICAgICAgICAgICBoaWdoLAorICAgICAgICAgICAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19y dmFsdWVfZnJvbV9pbnQgKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMyKSksCisg ICAgICAgICAgICAgbG93KSk7Cit9CisKK3N0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCitlbWl0X3J2 YWx1ZV9mcm9tX2VtYWNzX3VpbnQgKEVNQUNTX1VJTlQgdmFsKQoreworICBpZiAodmFsICE9IChs b25nKSB2YWwpCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVl X2Zyb21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29tcC5lbWFjc191aW50X3R5cGUsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWwpOworICAgIH0KKyAgZWxzZQor ICAgIHsKKyAgICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX3Vuc2lnbmVkX2xvbmdfbG9uZyAo Y29tcC5lbWFjc191aW50X3R5cGUsIHZhbCk7CisgICAgfQorfQorCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9ydmFsdWVfZnJvbV9lbWFjc19pbnQgKEVNQUNTX0lOVCB2YWwpCit7Cisg IGlmICh2YWwgIT0gKGxvbmcpIHZhbCkKKyAgICB7CisgICAgICByZXR1cm4gZW1pdF9ydmFsdWVf ZnJvbV9sb25nX2xvbmcgKGNvbXAuZW1hY3NfaW50X3R5cGUsIHZhbCk7CisgICAgfQorICBlbHNl CisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9u ZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29tcC5lbWFjc19pbnRfdHlwZSwgdmFsKTsKKyAgICB9Cit9CisKK3N0YXRpYyBn Y2Nfaml0X3J2YWx1ZSAqCitlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfd29yZF90YWcgKExpc3BfV29y ZF90YWcgdmFsKQogewotI2lmIEVNQUNTX0lOVF9NQVggPiBMT05HX01BWAotICByZXR1cm4gZW1p dF9ydmFsdWVfZnJvbV9sb25nX2xvbmcgKE1PU1RfUE9TSVRJVkVfRklYTlVNKTsKKyAgaWYgKHZh bCAhPSAobG9uZykgdmFsKQorICAgIHsKKyAgICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX3Vu c2lnbmVkX2xvbmdfbG9uZyAoY29tcC5saXNwX3dvcmRfdGFnX3R5cGUsIHZhbCk7CisgICAgfQor ICBlbHNlCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zy b21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdGFnX3R5cGUsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWwpOworICAgIH0KK30KKworc3Rh dGljIGdjY19qaXRfcnZhbHVlICoKK2VtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkIChMaXNwX1dv cmQgdmFsKQoreworI2lmIExJU1BfV09SRFNfQVJFX1BPSU5URVJTCisgIHJldHVybiBnY2Nfaml0 X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX3B0ciAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXAubGlzcF93b3JkX3R5cGUsCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsKICNlbHNlCi0g IHJldHVybiBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcgKGNvbXAuY3R4dCwK LQkJCQkJICAgICAgIGNvbXAuZW1hY3NfaW50X3R5cGUsCi0JCQkJCSAgICAgICBNT1NUX1BPU0lU SVZFX0ZJWE5VTSk7CisgIGlmICh2YWwgIT0gKGxvbmcpIHZhbCkKKyAgICB7CisgICAgICByZXR1 cm4gZW1pdF9ydmFsdWVfZnJvbV91bnNpZ25lZF9sb25nX2xvbmcgKGNvbXAubGlzcF93b3JkX3R5 cGUsIHZhbCk7CisgICAgfQorICBlbHNlCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29u dGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdHlwZSwKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhbCk7Cisg ICAgfQogI2VuZGlmCiB9CiAKIHN0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCi1lbWl0X21vc3RfbmVn YXRpdmVfZml4bnVtICh2b2lkKQorZW1pdF9ydmFsdWVfZnJvbV9saXNwX29iaiAoTGlzcF9PYmpl Y3Qgb2JqKQogewotI2lmIEVNQUNTX0lOVF9NQVggPiBMT05HX01BWAotICByZXR1cm4gZW1pdF9y dmFsdWVfZnJvbV9sb25nX2xvbmcgKE1PU1RfTkVHQVRJVkVfRklYTlVNKTsKKyNpZmRlZiBMSVNQ X09CSkVDVF9JU19TVFJVQ1QKKyAgcmV0dXJuIGVtaXRfY29lcmNlKGNvbXAubGlzcF9vYmpfdHlw ZSwKKyAgICAgICAgICAgICAgICAgICAgIGVtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkIChvYmou aSkpOwogI2Vsc2UKLSAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9u ZyAoY29tcC5jdHh0LAotCQkJCQkgICAgICAgY29tcC5lbWFjc19pbnRfdHlwZSwKLQkJCQkJICAg ICAgIE1PU1RfTkVHQVRJVkVfRklYTlVNKTsKKyAgcmV0dXJuIGVtaXRfcnZhbHVlX2Zyb21fbGlz cF93b3JkIChvYmopOwogI2VuZGlmCiB9CiAKK3N0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCitlbWl0 X21vc3RfcG9zaXRpdmVfZml4bnVtICh2b2lkKQoreworICByZXR1cm4gZW1pdF9ydmFsdWVfZnJv bV9lbWFjc19pbnQoTU9TVF9QT1NJVElWRV9GSVhOVU0pOworfQorCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9tb3N0X25lZ2F0aXZlX2ZpeG51bSAodm9pZCkKK3sKKyAgcmV0dXJuIGVt aXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX05FR0FUSVZFX0ZJWE5VTSk7Cit9CisKIC8q CiAgICBFbWl0IHRoZSBlcXVpdmFsZW50IG9mOgogICAgKHR5cGVvZl9wdHIpICgodWludHB0cikg cHRyICsgc2l6ZV9vZl9wdHJfcmVmICogaSkKQEAgLTc2OSw3ICs5MDcsNyBAQCBlbWl0X3B0cl9h cml0aG1ldGljIChnY2Nfaml0X3J2YWx1ZSAqcHRyLCBnY2Nfaml0X3R5cGUgKnB0cl90eXBlLAog ZW1pdF9YTEkgKGdjY19qaXRfcnZhbHVlICpvYmopCiB7CiAgIGVtaXRfY29tbWVudCAoIlhMSSIp OwotICByZXR1cm4gb2JqOworICByZXR1cm4gZW1pdF9jb2VyY2UgKGNvbXAuZW1hY3NfaW50X3R5 cGUsIG9iaik7CiB9CiAKIHN0YXRpYyBnY2Nfaml0X2x2YWx1ZSAqCkBAIC03NzksNTQgKzkxNyw0 MCBAQCBlbWl0X2x2YWxfWExJIChnY2Nfaml0X2x2YWx1ZSAqb2JqKQogICByZXR1cm4gb2JqOwog fQogCi0vKgorCiBzdGF0aWMgZ2NjX2ppdF9ydmFsdWUgKgogZW1pdF9YTFAgKGdjY19qaXRfcnZh bHVlICpvYmopCiB7CiAgIGVtaXRfY29tbWVudCAoIlhMUCIpOwogCi0gIHJldHVybiBnY2Nfaml0 X3J2YWx1ZV9hY2Nlc3NfZmllbGQgKG9iaiwKLQkJCQkgICAgICBOVUxMLAotCQkJCSAgICAgIGNv bXAubGlzcF9vYmpfYXNfcHRyKTsKKyAgcmV0dXJuIGVtaXRfY29lcmNlKGNvbXAudm9pZF9wdHJf dHlwZSwgb2JqKTsKIH0KIAotc3RhdGljIGdjY19qaXRfbHZhbHVlICoKLWVtaXRfbHZhbF9YTFAg KGdjY19qaXRfbHZhbHVlICpvYmopCi17Ci0gIGVtaXRfY29tbWVudCAoImx2YWxfWExQIik7Cisv KiBUT0RPICovCisvKiBzdGF0aWMgZ2NjX2ppdF9sdmFsdWUgKiAqLworLyogZW1pdF9sdmFsX1hM UCAoZ2NjX2ppdF9sdmFsdWUgKm9iaikgKi8KKy8qIHsgKi8KKy8qICAgZW1pdF9jb21tZW50ICgi bHZhbF9YTFAiKTsgKi8KKworLyogICByZXR1cm4gZ2NjX2ppdF9sdmFsdWVfYWNjZXNzX2ZpZWxk IChvYmosICovCisvKiAJCQkJICAgICAgTlVMTCwgKi8KKy8qIAkJCQkgICAgICBjb21wLmxpc3Bf b2JqX2FzX3B0cik7ICovCisvKiB9ICovCiAKLSAgcmV0dXJuIGdjY19qaXRfbHZhbHVlX2FjY2Vz c19maWVsZCAob2JqLAotCQkJCSAgICAgIE5VTEwsCi0JCQkJICAgICAgY29tcC5saXNwX29ial9h c19wdHIpOwotfSAqLwogc3RhdGljIGdjY19qaXRfcnZhbHVlICoKLWVtaXRfWFVOVEFHIChnY2Nf aml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF90eXBlICp0eXBlLCBsb25nIGxvbmcgbGlzcF93b3JkX3Rh ZykKK2VtaXRfWFVOVEFHIChnY2Nfaml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF90eXBlICp0eXBlLCBM aXNwX1dvcmRfdGFnIGxpc3Bfd29yZF90YWcpCiB7CiAgIC8qICNkZWZpbmUgWFVOVEFHKGEsIHR5 cGUsIGN0eXBlKSAoKGN0eXBlICopCiAgICAgICgoY2hhciAqKSBYTFAgKGEpIC0gTElTUF9XT1JE X1RBRyAodHlwZSkpKSAqLwogICBlbWl0X2NvbW1lbnQgKCJYVU5UQUciKTsKIAotI2lmbmRlZiBX SURFX0VNQUNTX0lOVAogICByZXR1cm4gZW1pdF9jb2VyY2UgKAogCSAgIGdjY19qaXRfdHlwZV9n ZXRfcG9pbnRlciAodHlwZSksCiAJICAgZW1pdF9iaW5hcnlfb3AgKAogCSAgICAgR0NDX0pJVF9C SU5BUllfT1BfTUlOVVMsCi0JICAgICBjb21wLmVtYWNzX2ludF90eXBlLAotCSAgICAgZW1pdF9Y TEkgKGEpLAotCSAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKAotCSAg ICAgICBjb21wLmN0eHQsCi0JICAgICAgIGNvbXAuZW1hY3NfaW50X3R5cGUsCi0JICAgICAgIGxp c3Bfd29yZF90YWcpKSk7Ci0jZWxzZQotICByZXR1cm4gZW1pdF9jb2VyY2UgKAotCSAgIGdjY19q aXRfdHlwZV9nZXRfcG9pbnRlciAodHlwZSksCi0JICAgZW1pdF9iaW5hcnlfb3AgKAotCSAgICAg R0NDX0pJVF9CSU5BUllfT1BfTUlOVVMsCi0JICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190 eXBlLAotCSAgICAgLyogRklYTUUgU2hvdWxkIGJlIFhMUC4gICovCi0JICAgICBlbWl0X1hMSSAo YSksCi0JICAgICBlbWl0X3J2YWx1ZV9mcm9tX2xvbmdfbG9uZyAobGlzcF93b3JkX3RhZykpKTsK LSNlbmRpZgorCSAgICAgY29tcC51aW50cHRyX3R5cGUsCisJICAgICBlbWl0X1hMUCAoYSksCisJ ICAgICBlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfd29yZF90YWcobGlzcF93b3JkX3RhZykpKTsKIH0K IAogc3RhdGljIGdjY19qaXRfcnZhbHVlICoKQEAgLTg1Myw3ICs5NzcsNyBAQCBlbWl0X0VRIChn Y2Nfaml0X3J2YWx1ZSAqeCwgZ2NjX2ppdF9ydmFsdWUgKnkpCiB9CiAKIHN0YXRpYyBnY2Nfaml0 X3J2YWx1ZSAqCi1lbWl0X1RBR0dFRFAgKGdjY19qaXRfcnZhbHVlICpvYmosIHB0cmRpZmZfdCB0 YWcpCitlbWl0X1RBR0dFRFAgKGdjY19qaXRfcnZhbHVlICpvYmosIExpc3BfV29yZF90YWcgdGFn KQogewogICAgLyogKCEgKCgodW5zaWduZWQpIChYTEkgKGEpID4+IChVU0VfTFNCX1RBRyA/IDAg OiBWQUxCSVRTKSkgXAogCS0gKHVuc2lnbmVkKSAodGFnKSkgXApAQCAtMTA1NCwxNyArMTE3OCw3 IEBAIGVtaXRfbWFrZV9maXhudW1fTFNCX1RBRyAoZ2NjX2ppdF9ydmFsdWUgKm4pCiAJCQljb21w LmVtYWNzX2ludF90eXBlLAogCQkJdG1wLCBjb21wLmxpc3BfaW50MCk7CiAKLSAgZ2NjX2ppdF9s dmFsdWUgKnJlcyA9IGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsIChjb21wLmZ1bmMsCi0JCQkJ CQkgICAgTlVMTCwKLQkJCQkJCSAgICBjb21wLmxpc3Bfb2JqX3R5cGUsCi0JCQkJCQkgICAgImxp c3Bfb2JqX2ZpeG51bSIpOwotCi0gIGdjY19qaXRfYmxvY2tfYWRkX2Fzc2lnbm1lbnQgKGNvbXAu YmxvY2ssCi0JCQkJTlVMTCwKLQkJCQllbWl0X2x2YWxfWExJIChyZXMpLAotCQkJCXRtcCk7Ci0K LSAgcmV0dXJuIGdjY19qaXRfbHZhbHVlX2FzX3J2YWx1ZSAocmVzKTsKKyAgcmV0dXJuIGVtaXRf Y29lcmNlIChjb21wLmxpc3Bfb2JqX3R5cGUsIHRtcCk7CiB9CiAKIHN0YXRpYyBnY2Nfaml0X3J2 YWx1ZSAqCkBAIC0xMDc2LDEwICsxMTkwLDggQEAgZW1pdF9tYWtlX2ZpeG51bV9NU0JfVEFHIChn Y2Nfaml0X3J2YWx1ZSAqbikKICAgICByZXR1cm4gWElMIChuKTsKICAgKi8KIAotICBnY2Nfaml0 X3J2YWx1ZSAqaW50bWFzayA9Ci0gICAgZW1pdF9jb2VyY2UgKGNvbXAuZW1hY3NfdWludF90eXBl LAotCQkgZW1pdF9ydmFsdWVfZnJvbV9sb25nX2xvbmcgKChFTUFDU19JTlRfTUFYCi0JCQkJCSAg ICAgID4+IChJTlRUWVBFQklUUyAtIDEpKSkpOworICBnY2Nfaml0X3J2YWx1ZSAqaW50bWFzayA9 IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfdWludCAoSU5UTUFTSyk7CisKICAgbiA9IGVtaXRfYmlu YXJ5X29wIChHQ0NfSklUX0JJTkFSWV9PUF9CSVRXSVNFX0FORCwKIAkJICAgICAgY29tcC5lbWFj c191aW50X3R5cGUsCiAJCSAgICAgIGludG1hc2ssIG4pOwpAQCAtMTA5MCwxMiArMTIwMiwxMCBA QCBlbWl0X21ha2VfZml4bnVtX01TQl9UQUcgKGdjY19qaXRfcnZhbHVlICpuKQogCQkgICAgZW1p dF9iaW5hcnlfb3AgKEdDQ19KSVRfQklOQVJZX09QX0xTSElGVCwKIAkJCQkgICAgY29tcC5lbWFj c191aW50X3R5cGUsCiAJCQkJICAgIGNvbXAubGlzcF9pbnQwLAotCQkJCSAgICBnY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCAoCi0JCQkJICAgICAgY29tcC5jdHh0LAotCQkJCSAg ICAgIGNvbXAuZW1hY3NfdWludF90eXBlLAotCQkJCSAgICAgIFZBTEJJVFMpKSwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfdWludChW QUxCSVRTKSksCiAJCSAgICBuKTsKLSAgcmV0dXJuIGVtaXRfWExJIChlbWl0X2NvZXJjZSAoY29t cC5lbWFjc19pbnRfdHlwZSwgbikpOworCisgIHJldHVybiBlbWl0X2NvZXJjZSAoY29tcC5saXNw X29ial90eXBlLCBuKTsKIH0KIAogCkBAIC0xMTE0LDE3ICsxMjI0LDEwIEBAIGVtaXRfY29uc3Rf bGlzcF9vYmogKExpc3BfT2JqZWN0IG9iaikKICAgZW1pdF9jb21tZW50IChmb3JtYXRfc3RyaW5n ICgiY29uc3QgbGlzcCBvYmo6ICVzIiwKIAkJCSAgICAgICBTU0RBVEEgKEZwcmluMV90b19zdHJp bmcgKG9iaiwgUW5pbCkpKSk7CiAKLSAgaWYgKE5JTF9JU19aRVJPICYmIEVRIChvYmosIFFuaWwp KQorICBpZiAoRVEgKG9iaiwgUW5pbCkpCiAgICAgewogICAgICAgZ2NjX2ppdF9ydmFsdWUgKm47 Ci0jaWZkZWYgV0lERV9FTUFDU19JTlQKLSAgICAgIGVhc3NlcnQgKE5JTF9JU19aRVJPKTsKLSAg ICAgIG4gPSBlbWl0X3J2YWx1ZV9mcm9tX2xvbmdfbG9uZyAoMCk7Ci0jZWxzZQotICAgICAgbiA9 IGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIChjb21wLmN0eHQsCi0JCQkJCSAg ICAgICBjb21wLnZvaWRfcHRyX3R5cGUsCi0JCQkJCSAgICAgICBOVUxMKTsKLSNlbmRpZgorICAg ICAgbiA9IGVtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkICgoTGlzcF9Xb3JkKSBpUW5pbCk7CiAg ICAgICByZXR1cm4gZW1pdF9jb2VyY2UgKGNvbXAubGlzcF9vYmpfdHlwZSwgbik7CiAgICAgfQog CkBAIC0xMzQ1LDE2ICsxNDQ4LDcgQEAgZW1pdF9tdmFyX3ZhbCAoTGlzcF9PYmplY3QgbXZhcikK IAkgIC8qIFdlIGNhbiBzdGlsbCBlbWl0IGRpcmVjdGx5IG9iamVjdHMgdGhhdCBhcmUgc2VsZi1j b250YWluZWQgaW4gYQogCSAgICAgd29yZCAocmVhZCBmaXhudW1zKS4gICovCiAJICBlbWl0X2Nv bW1lbnQgKFNTREFUQSAoRnByaW4xX3RvX3N0cmluZyAoY29uc3RhbnQsIFFuaWwpKSk7Ci0JICBn Y2Nfaml0X3J2YWx1ZSAqd29yZDsKLSNpZmRlZiBXSURFX0VNQUNTX0lOVAotCSAgd29yZCA9IGVt aXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChjb25zdGFudCk7Ci0jZWxzZQotCSAgd29yZCA9Ci0J ICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIChjb21wLmN0eHQsCi0JCQkJ CQkgY29tcC52b2lkX3B0cl90eXBlLAotCQkJCQkJIFhMUCAoY29uc3RhbnQpKTsKLSNlbmRpZgot CSAgcmV0dXJuIGVtaXRfY29lcmNlIChjb21wLmxpc3Bfb2JqX3R5cGUsIHdvcmQpOworICAgICAg ICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfb2JqKGNvbnN0YW50KTsKIAl9CiAgICAg ICAvKiBPdGhlciBjb25zdCBvYmplY3RzIGFyZSBmZXRjaGVkIGZyb20gdGhlIHJlbG9jIGFycmF5 LiAgKi8KICAgICAgIHJldHVybiBlbWl0X2NvbnN0X2xpc3Bfb2JqIChjb25zdGFudCk7CkBAIC0y NTE4LDExICsyNjEyLDE2IEBAIGRlZmluZV9jYXN0X3VuaW9uICh2b2lkKQogCQkJICAgICAgIE5V TEwsCiAJCQkgICAgICAgY29tcC5saXNwX2NvbnNfcHRyX3R5cGUsCiAJCQkgICAgICAgImNvbnNf cHRyIik7Ci0gIGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29iaiA9CisgIGNvbXAuY2FzdF91bmlv bl9hc19saXNwX3dvcmQgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4 dCwKIAkJCSAgICAgICBOVUxMLAotCQkJICAgICAgIGNvbXAubGlzcF9vYmpfdHlwZSwKLQkJCSAg ICAgICAibGlzcF9vYmoiKTsKKwkJCSAgICAgICBjb21wLmxpc3Bfd29yZF90eXBlLAorCQkJICAg ICAgICJsaXNwX3dvcmQiKTsKKyAgY29tcC5jYXN0X3VuaW9uX2FzX2xpc3Bfd29yZF90YWcgPQor ICAgIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bXAubGlzcF93b3JkX3RhZ190eXBlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJs aXNwX3dvcmRfdGFnIik7CiAgIGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29ial9wdHIgPQogICAg IGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKIAkJCSAgICAgICBOVUxMLApA QCAtMjU0Myw3ICsyNjQyLDggQEAgZGVmaW5lX2Nhc3RfdW5pb24gKHZvaWQpCiAgICAgICBjb21w LmNhc3RfdW5pb25fYXNfY19wLAogICAgICAgY29tcC5jYXN0X3VuaW9uX2FzX3ZfcCwKICAgICAg IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX2NvbnNfcHRyLAotICAgICAgY29tcC5jYXN0X3VuaW9u X2FzX2xpc3Bfb2JqLAorICAgICAgY29tcC5jYXN0X3VuaW9uX2FzX2xpc3Bfd29yZCwKKyAgICAg IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX3dvcmRfdGFnLAogICAgICAgY29tcC5jYXN0X3VuaW9u X2FzX2xpc3Bfb2JqX3B0ciB9OwogICBjb21wLmNhc3RfdW5pb25fdHlwZSA9CiAgICAgZ2NjX2pp dF9jb250ZXh0X25ld191bmlvbl90eXBlIChjb21wLmN0eHQsCkBAIC0yODEwLDggKzI5MTAsOCBA QCBkZWZpbmVfYWRkMV9zdWIxICh2b2lkKQogCQkJCQkgIEdDQ19KSVRfQ09NUEFSSVNPTl9ORSwK IAkJCQkJICBuX2ZpeG51bSwKIAkJCQkJICBpID09IDAKLQkJCQkJICA/IGVtaXRfbW9zdF9wb3Np dGl2ZV9maXhudW0gKCkKLQkJCQkJICA6IGVtaXRfbW9zdF9uZWdhdGl2ZV9maXhudW0gKCkpKSwK KwkJCQkJICA/IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX1BPU0lUSVZFX0ZJWE5V TSkKKwkJCQkJICA6IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX05FR0FUSVZFX0ZJ WE5VTSkpKSwKIAlpbmxpbmVfYmxvY2ssCiAJZmNhbGxfYmxvY2spOwogCkBAIC0zMzA3LDkgKzM0 MDcsMzEgQEAgREVGVU4gKCJjb21wLS1pbml0LWN0eHQiLCBGY29tcF9faW5pdF9jdHh0LCBTY29t cF9faW5pdF9jdHh0LAogICBjb21wLmVtYWNzX3VpbnRfdHlwZSA9IGdjY19qaXRfY29udGV4dF9n ZXRfaW50X3R5cGUgKGNvbXAuY3R4dCwKIAkJCQkJCSAgICAgICBzaXplb2YgKEVNQUNTX1VJTlQp LAogCQkJCQkJICAgICAgIGZhbHNlKTsKLSAgLyogTm8gWExQIGlzIGVtaXR0ZWQgZm9yIG5vdyBz byBsZXRzIGRlZmluZSB0aGlzIGFsd2F5cyBhcyBpbnRlZ2VyCi0gICAgIGRpc3JlZ2FyZGluZyBM SVNQX1dPUkRTX0FSRV9QT0lOVEVSUyB2YWx1ZS4gICovCi0gIGNvbXAubGlzcF9vYmpfdHlwZSA9 IGNvbXAuZW1hY3NfaW50X3R5cGU7CisjaWYgTElTUF9XT1JEU19BUkVfUE9JTlRFUlMKKyAgY29t cC5saXNwX1hfcyA9IGdjY19qaXRfY29udGV4dF9uZXdfb3BhcXVlX3N0cnVjdCAoY29tcC5jdHh0 LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBO VUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAiTGlzcF9YIik7CisgIGNvbXAubGlzcF9YID0gZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZShjb21w Lmxpc3BfWF9zKTsKKyAgY29tcC5saXNwX3dvcmRfdHlwZSA9IGdjY19qaXRfdHlwZV9nZXRfcG9p bnRlcihjb21wLmxpc3BfWCk7CisjZWxzZQorICBjb21wLmxpc3Bfd29yZF90eXBlID0gY29tcC5l bWFjc19pbnRfdHlwZTsKKyNlbmRpZgorICBjb21wLmxpc3Bfd29yZF90YWdfdHlwZQorICAgID0g Z2NjX2ppdF9jb250ZXh0X2dldF9pbnRfdHlwZSAoY29tcC5jdHh0LCBzaXplb2YgKExpc3BfV29y ZF90YWcpLCBmYWxzZSk7CisjaWZkZWYgTElTUF9PQkpFQ1RfSVNfU1RSVUNUCisgIGNvbXAubGlz cF9vYmpfaSA9IGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdHlwZSwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImkiKTsKKyAg Y29tcC5saXNwX29ial9zID0gZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfdHlwZSAoY29tcC5j dHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiTGlzcF9PYmplY3QiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAxLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmY29tcC5saXNwX29ial9pKTsKKyAgY29tcC5saXNwX29ial90eXBl ID0gZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZSAoY29tcC5saXNwX29ial9zKTsKKyNlbHNlCisgIGNv bXAubGlzcF9vYmpfdHlwZSA9IGNvbXAubGlzcF93b3JkX3R5cGU7CisjZW5kaWYKICAgY29tcC5s aXNwX29ial9wdHJfdHlwZSA9IGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciAoY29tcC5saXNwX29i al90eXBlKTsKICAgY29tcC5vbmUgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zy b21faW50IChjb21wLmN0eHQsCmRpZmYgLS1naXQgYS9zcmMvbGlzcC5oIGIvc3JjL2xpc3AuaApp bmRleCAzZDA4MjkxMWY1Li5lM2QxOTZlZjliIDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBi L3NyYy9saXNwLmgKQEAgLTI5OSwxMiArMjk5LDEyIEBAICNkZWZpbmUgR0NBTElHTkVEKHR5cGUp IChhbGlnbm9mICh0eXBlKSAlIEdDQUxJR05NRU5UID09IDApCiAKIC8qIExpc3BfV29yZCBpcyBh IHNjYWxhciB3b3JkIHN1aXRhYmxlIGZvciBob2xkaW5nIGEgdGFnZ2VkIHBvaW50ZXIgb3IKICAg IGludGVnZXIuICBVc3VhbGx5IGl0IGlzIGEgcG9pbnRlciB0byBhIGRlbGliZXJhdGVseS1pbmNv bXBsZXRlIHR5cGUKLSAgICd1bmlvbiBMaXNwX1gnLiAgSG93ZXZlciwgaXQgaXMgRU1BQ1NfSU5U IHdoZW4gTGlzcF9PYmplY3RzIGFuZAorICAgJ3N0cnVjdCBMaXNwX1gnLiAgSG93ZXZlciwgaXQg aXMgRU1BQ1NfSU5UIHdoZW4gTGlzcF9PYmplY3RzIGFuZAogICAgcG9pbnRlcnMgZGlmZmVyIGlu IHdpZHRoLiAgKi8KIAogI2RlZmluZSBMSVNQX1dPUkRTX0FSRV9QT0lOVEVSUyAoRU1BQ1NfSU5U X01BWCA9PSBJTlRQVFJfTUFYKQogI2lmIExJU1BfV09SRFNfQVJFX1BPSU5URVJTCi10eXBlZGVm IHVuaW9uIExpc3BfWCAqTGlzcF9Xb3JkOwordHlwZWRlZiBzdHJ1Y3QgTGlzcF9YICpMaXNwX1dv cmQ7CiAjZWxzZQogdHlwZWRlZiBFTUFDU19JTlQgTGlzcF9Xb3JkOwogI2VuZGlmCkBAIC01NzMs NiArNTczLDcgQEAgI2RlZmluZSBFTlVNX0JGKFRZUEUpIGVudW0gVFlQRQogCiAjaWZkZWYgQ0hF Q0tfTElTUF9PQkpFQ1RfVFlQRQogdHlwZWRlZiBzdHJ1Y3QgTGlzcF9PYmplY3QgeyBMaXNwX1dv cmQgaTsgfSBMaXNwX09iamVjdDsKKyMgZGVmaW5lIExJU1BfT0JKRUNUX0lTX1NUUlVDVAogIyBk ZWZpbmUgTElTUF9JTklUSUFMTFkodykge3d9CiAjIHVuZGVmIENIRUNLX0xJU1BfT0JKRUNUX1RZ UEUKIGVudW0gQ0hFQ0tfTElTUF9PQkpFQ1RfVFlQRSB7IENIRUNLX0xJU1BfT0JKRUNUX1RZUEUg PSB0cnVlIH07Ci0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch" Content-Disposition: attachment; filename="0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdf54 RnJvbSA3MTczMDFiZjNmMWY3MzU2OTc2NWNjZDg4ZTE2MWM3M2MzM2M3MDAxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE2OjIz OjEwIC0wMzAwClN1YmplY3Q6IFtQQVRDSCA1LzhdIFJlbW92ZSBhIGxheWVyIG9mIGluZGlyZWN0 aW9uIGZvciBhY2Nlc3MgdG8gcHVyZSBzdG9yYWdlLgoKKiBzcmMvY29tcC5jOiBUYWtpbmcgdGhl IGFkZHJlc3Mgb2YgYW4gYXJyYXkgaXMgdGhlIHNhbWUgYXMgY2FzdGluZyBpdAp0byBhIHBvaW50 ZXIuIFRoZXJlZm9yZSwgdGhlIEMgZXhwcmVzc2lvbiBgKEVNQUNTX0lOVCAqKikgJnB1cmVgIGlz IGluCmZhY3QgYWRkaW5nIGEgbGF5ZXIgb2YgaW5kaXJlY3Rpb24gdGhhdCBpcyBub3QgbmVjZXNz YXJ5LiBUaGUgZml4IGlzCnRvIGNhc3QgdGhlIGBwdXJlYCBhcnJheSB0byBhIHBvaW50ZXIgYW5k IHN0b3JlIHRoYXQgaW4gYSB2b2lkIHBvaW50ZXIKdGhhdCBpcyBwYXJ0IG9mIHRoZSBjb21waWxl ZCBzaGFyZWQgbGlicmFyeS4KLS0tCiBzcmMvY29tcC5jIHwgMTkgKysrKysrKysrLS0tLS0tLS0t LQogMSBmaWxlIGNoYW5nZWQsIDkgaW5zZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pCgpkaWZm IC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9jb21wLmMKaW5kZXggMGQ1ODgwYWQzYy4uNjk1MjVh Y2ZjMCAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9zcmMvY29tcC5jCkBAIC0zOCw3ICsz OCw3IEBACiAKIC8qIEMgc3ltYm9scyBlbWl0dGVkIGZvciB0aGUgbG9hZCByZWxvY2F0aW9uIG1l Y2hhbmlzbS4gICovCiAjZGVmaW5lIENVUlJFTlRfVEhSRUFEX1JFTE9DX1NZTSAiY3VycmVudF90 aHJlYWRfcmVsb2MiCi0jZGVmaW5lIFBVUkVfUkVMT0NfU1lNICJwdXJlX3JlbG9jIgorI2RlZmlu ZSBQVVJFX1BUUl9TWU0gInB1cmVfcHRyIgogI2RlZmluZSBEQVRBX1JFTE9DX1NZTSAiZF9yZWxv YyIKICNkZWZpbmUgREFUQV9SRUxPQ19JTVBVUkVfU1lNICJkX3JlbG9jX2ltcCIKICNkZWZpbmUg REFUQV9SRUxPQ19FUEhFTUVSQUxfU1lNICJkX3JlbG9jX2VwaCIKQEAgLTE1Miw3ICsxNTIsNyBA QCAjZGVmaW5lIEZfUkVMT0NfTUFYX1NJWkUgMTUwMAogICBnY2Nfaml0X3R5cGUgKnRocmVhZF9z dGF0ZV9wdHJfdHlwZTsKICAgZ2NjX2ppdF9ydmFsdWUgKmN1cnJlbnRfdGhyZWFkX3JlZjsKICAg LyogT3RoZXIgZ2xvYmFscy4gICovCi0gIGdjY19qaXRfcnZhbHVlICpwdXJlX3JlZjsKKyAgZ2Nj X2ppdF9ydmFsdWUgKnB1cmVfcHRyOwogICAvKiBsaWJnY2NqaXQgaGFzIHJlYWxseSBsaW1pdGVk IHN1cHBvcnQgZm9yIGNhc3RpbmcgdGhlcmVmb3JlIHRoaXMgdW5pb24gd2lsbAogICAgICBiZSB1 c2VkIGZvciB0aGUgc2NvcGUuICAqLwogICBnY2Nfaml0X3R5cGUgKmNhc3RfdW5pb25fdHlwZTsK QEAgLTE0MTksOCArMTQxOSw3IEBAIGVtaXRfUFVSRV9QIChnY2Nfaml0X3J2YWx1ZSAqcHRyKQog CUdDQ19KSVRfQklOQVJZX09QX01JTlVTLAogCWNvbXAudWludHB0cl90eXBlLAogCXB0ciwKLQln Y2Nfaml0X2x2YWx1ZV9hc19ydmFsdWUgKAotCSAgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2Ug KGNvbXAucHVyZV9yZWYsIE5VTEwpKSksCisgICAgICAgIGNvbXAucHVyZV9wdHIpLAogICAgICAg Z2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKGNvbXAuY3R4dCwKIAkJCQkJICAg Y29tcC51aW50cHRyX3R5cGUsCiAJCQkJCSAgIFBVUkVTSVpFKSk7CkBAIC0yMjQ0LDE0ICsyMjQz LDE0IEBAIGVtaXRfY3R4dF9jb2RlICh2b2lkKQogCWdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciAo Y29tcC50aHJlYWRfc3RhdGVfcHRyX3R5cGUpLAogCUNVUlJFTlRfVEhSRUFEX1JFTE9DX1NZTSkp OwogCi0gIGNvbXAucHVyZV9yZWYgPQorICBjb21wLnB1cmVfcHRyID0KICAgICBnY2Nfaml0X2x2 YWx1ZV9hc19ydmFsdWUgKAogICAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19nbG9iYWwgKAogCWNv bXAuY3R4dCwKIAlOVUxMLAogCUdDQ19KSVRfR0xPQkFMX0VYUE9SVEVELAotCWdjY19qaXRfdHlw ZV9nZXRfcG9pbnRlciAoY29tcC52b2lkX3B0cl90eXBlKSwKLQlQVVJFX1JFTE9DX1NZTSkpOwor ICAgICAgICBjb21wLnZvaWRfcHRyX3R5cGUsCisJUFVSRV9QVFJfU1lNKSk7CiAKICAgZ2NjX2pp dF9jb250ZXh0X25ld19nbG9iYWwgKAogCWNvbXAuY3R4dCwKQEAgLTM3NjcsMTMgKzM3NjYsMTMg QEAgbG9hZF9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKmNvbXBfdSwg Ym9vbCBsb2FkaW5nX2R1bXAsCiAgICAgewogICAgICAgc3RydWN0IHRocmVhZF9zdGF0ZSAqKipj dXJyZW50X3RocmVhZF9yZWxvYyA9CiAJZHlubGliX3N5bSAoaGFuZGxlLCBDVVJSRU5UX1RIUkVB RF9SRUxPQ19TWU0pOwotICAgICAgRU1BQ1NfSU5UICoqKnB1cmVfcmVsb2MgPSBkeW5saWJfc3lt IChoYW5kbGUsIFBVUkVfUkVMT0NfU1lNKTsKKyAgICAgIHZvaWQgKipwdXJlX3B0ciA9IGR5bmxp Yl9zeW0gKGhhbmRsZSwgUFVSRV9QVFJfU1lNKTsKICAgICAgIExpc3BfT2JqZWN0ICpkYXRhX3Jl bG9jcyA9IGR5bmxpYl9zeW0gKGhhbmRsZSwgREFUQV9SRUxPQ19TWU0pOwogICAgICAgTGlzcF9P YmplY3QgKmRhdGFfaW1wX3JlbG9jcyA9IGR5bmxpYl9zeW0gKGhhbmRsZSwgREFUQV9SRUxPQ19J TVBVUkVfU1lNKTsKICAgICAgIHZvaWQgKipmcmVsb2NfbGlua190YWJsZSA9IGR5bmxpYl9zeW0g KGhhbmRsZSwgRlVOQ19MSU5LX1RBQkxFX1NZTSk7CiAKICAgICAgIGlmICghKGN1cnJlbnRfdGhy ZWFkX3JlbG9jCi0JICAgICYmIHB1cmVfcmVsb2MKKwkgICAgJiYgcHVyZV9wdHIKIAkgICAgJiYg ZGF0YV9yZWxvY3MKIAkgICAgJiYgZGF0YV9pbXBfcmVsb2NzCiAJICAgICYmIGRhdGFfZXBoX3Jl bG9jcwpAQCAtMzc4NCw3ICszNzgzLDcgQEAgbG9hZF9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05h dGl2ZV9Db21wX1VuaXQgKmNvbXBfdSwgYm9vbCBsb2FkaW5nX2R1bXAsCiAJeHNpZ25hbDEgKFFu YXRpdmVfbGlzcF9maWxlX2luY29uc2lzdGVudCwgY29tcF91LT5maWxlKTsKIAogICAgICAgKmN1 cnJlbnRfdGhyZWFkX3JlbG9jID0gJmN1cnJlbnRfdGhyZWFkOwotICAgICAgKnB1cmVfcmVsb2Mg PSAoRU1BQ1NfSU5UICoqKSZwdXJlOworICAgICAgKnB1cmVfcHRyID0gcHVyZTsKIAogICAgICAg LyogSW1wb3J0ZWQgZnVuY3Rpb25zLiAgKi8KICAgICAgICpmcmVsb2NfbGlua190YWJsZSA9IGZy ZWxvYy5saW5rX3RhYmxlOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0006-Workaround-the-32768-chars-command-line-limit-in-Win.patch" Content-Disposition: attachment; filename="0006-Workaround-the-32768-chars-command-line-limit-in-Win.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdfc5 RnJvbSA1Njc1OTRhMzVkNTczMDc4M2M5NGIyOGZkYmQ2YTI1MTA0NDg4MTIwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE0OjA0 OjA2IC0wMzAwClN1YmplY3Q6IFtQQVRDSCA2LzhdIFdvcmthcm91bmQgdGhlIDMyNzY4IGNoYXJz IGNvbW1hbmQgbGluZSBsaW1pdCBpbiBXaW5kb3dzLgoKKiBsaXNwL2VtYWNzLWxpc3AvY29tcC5l bCAoY29tcC1ydW4tYXN5bmMtd29ya2Vycyk6IFBhc3MgdGhlCmNvbXBpbGF0aW9uIGNvbW1hbmRz IHRocm91Z2ggYSB0ZW1wb3JhcnkgZmlsZSB0aGF0IGlzIGxvYWRlZCBieSB0aGUKY2hpbGQgcHJv Y2Vzcy4gVGhpcyBpcyBhbHNvIGRvbmUgYWxsIG90aGVyIG9wZXJhdGluZyBzeXN0ZW1zLCBldmVu CnRob3NlIHRoYXQgc3VwcG9ydCBsb25nIGNvbW1hbmQgbGluZXMuIEl0IHNob3VsZCBub3QgYmUg YSBwcm9ibGVtCnNpbmNlIGxpYmdjY2ppdCB1c2VzIHRlbXBvcmFyeSBmaWxlcyB0b28uCi0tLQog bGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgfCA2ICsrKysrLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5z ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9j b21wLmVsIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKaW5kZXggYzJhOTVmZWVjMS4uZDMyZjkz YTFlMSAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKKysrIGIvbGlzcC9lbWFj cy1saXNwL2NvbXAuZWwKQEAgLTIyMzksNiArMjIzOSw5IEBAIGNvbXAtcnVuLWFzeW5jLXdvcmtl cnMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWVzc2FnZSAiQ29tcGlsaW5nICVzLi4u IiAsc291cmNlLWZpbGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5hdGl2ZS1jb21w aWxlICxzb3VyY2UtZmlsZSAsKGFuZCBsb2FkIHQpKSkpCiAgICAgICAgICAgICAgICAgICAgKHNv dXJjZS1maWxlMSBzb3VyY2UtZmlsZSkgOzsgTWFrZSB0aGUgY2xvc3VyZSB3b3JrcyA6LworICAg ICAgICAgICAgICAgICAgICh0ZW1wLWZpbGUgKG1ha2UtdGVtcC1maWxlCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGNvbmNhdCAiZW1hY3MtYXN5bmMtY29tcC0iIChmaWxlLW5hbWUt YmFzZSBzb3VyY2UtZmlsZSkgIi0iKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5p bCAiLmVsIiAocHJpbjEtdG8tc3RyaW5nIGV4cHIpKSkKICAgICAgICAgICAgICAgICAgICAobG9h ZDEgbG9hZCkKICAgICAgICAgICAgICAgICAgICAocHJvY2VzcyAobWFrZS1wcm9jZXNzCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDpuYW1lIChjb25jYXQgIkNvbXBpbGluZzogIiBzb3Vy Y2UtZmlsZSkKQEAgLTIyNDYsMTMgKzIyNDksMTQgQEAgY29tcC1ydW4tYXN5bmMtd29ya2Vycwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6Y29tbWFuZCAobGlzdAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGV4cGFuZC1maWxlLW5hbWUgaW52b2NhdGlvbi1u YW1lCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpbnZvY2F0aW9uLWRpcmVjdG9yeSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICItLWJhdGNoIiAiLS1ldmFsIiAocHJpbjEtdG8tc3RyaW5nIGV4cHIpKQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi0tYmF0Y2giICItbCIgdGVtcC1m aWxlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6c2VudGluZWwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocHJvY2VzcyBfZXZlbnQpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHJ1bi1ob29rLXdpdGgtYXJncwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAnY29tcC1hc3luYy1jdS1kb25lLWhvb2sKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc291cmNlLWZpbGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGFjY2VwdC1wcm9jZXNzLW91dHB1dCBwcm9jZXNzKQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChpZ25vcmUtZXJyb3JzIChkZWxldGUtZmlsZSB0ZW1wLWZpbGUpKQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICh3aGVuIChhbmQgbG9hZDEKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICh6ZXJvcCAocHJvY2Vzcy1leGl0LXN0YXR1cyBw cm9jZXNzKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobmF0aXZlLWVsaXNw LWxvYWQKLS0gCjIuMjUuMS53aW5kb3dzLjEKCg== --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0007-Load-libgccjit-dynamically-in-Windows.patch" Content-Disposition: attachment; filename="0007-Load-libgccjit-dynamically-in-Windows.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdfj6 RnJvbSA1MTE5ODk4ZmJkMzQ3NzUyYzQ2YjA5ZGVlY2IyMzY1ZDZjN2ZjZTdmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAxMSBNYXkgMjAyMCAyMDo0 MzowNiAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggNy84XSBMb2FkIGxpYmdjY2ppdCBkeW5hbWljYWxs eSBpbiBXaW5kb3dzLgoKKiBjb25maWd1cmUuYWM6IGRvbid0IGFkZCBsaW5rZXIgZmxhZ3MgaWYg Y29tcGlsaW5nIG9uCldpbmRvd3MuIENvbXBpbGUgZHlubGliLmMgaWYgbW9kdWxlcyBvciBuYXRp dmUgY29tcGlsYXRpb24gYXJlCmVuYWJsZWQuIEFsd2F5cyBjb21waWxlIGNvbXAuYwoqIGxpc3Av dGVybS93MzItd2luLmVsOiBNYXAgJ2djY2ppdCB0byAibGliZ2Njaml0LmRsbCIgaW4KYGR5bmFt aWMtbGlicmFyeS1hbGlzdGAuCiogc3JjL01ha2VmaWxlLmluOiBVcGRhdGUgY29tbWVudHMuIFVw ZGF0ZSB0byBoYW5kbGUgY2hhbmdlcyBpbgpjb25maWd1cmUuYWMuCiogc3JjL2NvbXAuYzogQWRk IGRlY2xhcmF0aW9ucyBvZiB1c2VkIGxpYmdjY2ppdCBmdW5jdGlvbnMgdXNpbmcKREVGX0RMTF9G Ti4gQWRkIGNhbGxzIHRvIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSgpIHdoZXJlIG5lY2Vzc2Fy eS4KQWRkIGBuYXRpdmUtY29tcC1hdmFpbGFibGUtcGAKKiBzcmMvY29tcC5oOiBSZW1vdmUgRm5h dGl2ZV9lbGlzcF9sb2FkLiBBZGQgc3ltc19vZl9jb21wKCkuCiogc3JjL2VtYWNzLmMgKG1haW4p OiBBbHdheXMgY2FsbCBzeW1zX29mX2NvbXAoKQoqIHNyYy93MzIuYyAoZ2xvYmFsc19vZl93MzIp OiBDbGVhciBWbGlicmFyeV9jYWNoZSB3aGVuIHN0YXJ0aW5nCmJlY2F1c2UgdGhlIGxpYnJhcmll cyBsb2FkZWQgd2hlbiBkdW1waW5nIHdpbGwgbm90IGJlIGxvYWRlZCB3aGVuCnN0YXJ0aW5nLgoq IHNyYy93MzJmbnMuYzogQWRkIFFnY2NqaXQgc3ltYm9sLgotLS0KIGNvbmZpZ3VyZS5hYyAgICAg ICAgIHwgIDE5ICsrLQogbGlzcC90ZXJtL3czMi13aW4uZWwgfCAgIDMgKy0KIHNyYy9NYWtlZmls ZS5pbiAgICAgIHwgICA5ICstCiBzcmMvY29tcC5jICAgICAgICAgICB8IDM3NCArKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBzcmMvY29tcC5oICAgICAgICAgICB8 ICAgNiArLQogc3JjL2VtYWNzLmMgICAgICAgICAgfCAgIDIgLQogc3JjL3czMi5jICAgICAgICAg ICAgfCAgIDQgKwogc3JjL3czMmZucy5jICAgICAgICAgfCAgIDEgKwogOCBmaWxlcyBjaGFuZ2Vk LCAzOTggaW5zZXJ0aW9ucygrKSwgMjAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvY29uZmln dXJlLmFjIGIvY29uZmlndXJlLmFjCmluZGV4IDIzYjk0Y2Y2Y2EuLmVhMDE0NGY0MDQgMTAwNjQ0 Ci0tLSBhL2NvbmZpZ3VyZS5hYworKysgYi9jb25maWd1cmUuYWMKQEAgLTM2NjYsNiArMzY2Niw3 IEBAIEFDX0RFRlVOCiBMSUJNT0RVTEVTPQogSEFWRV9NT0RVTEVTPW5vCiBNT0RVTEVTX09CSj0K K05FRURfRFlOTElCPW5vCiBjYXNlICRvcHN5cyBpbgogICBjeWd3aW58bWluZ3czMikgTU9EVUxF U19TVUZGSVg9Ii5kbGwiIDs7CiAgIGRhcndpbikgTU9EVUxFU19TVUZGSVg9Ii5keWxpYiIgOzsK QEAgLTM3MDEsNyArMzcwMiw4IEBAIEFDX0RFRlVOCiBmaQogCiBpZiB0ZXN0ICIke0hBVkVfTU9E VUxFU30iID0geWVzOyB0aGVuCi0gICBNT0RVTEVTX09CSj0iZHlubGliLm8gZW1hY3MtbW9kdWxl Lm8iCisgICBNT0RVTEVTX09CSj0iZW1hY3MtbW9kdWxlLm8iCisgICBORUVEX0RZTkxJQj15ZXMK ICAgIEFDX0RFRklORShIQVZFX01PRFVMRVMsIDEsIFtEZWZpbmUgdG8gMSBpZiBkeW5hbWljIG1v ZHVsZXMgYXJlIGVuYWJsZWRdKQogICAgQUNfREVGSU5FX1VOUVVPVEVEKE1PRFVMRVNfU1VGRklY LCAiJE1PRFVMRVNfU1VGRklYIiwKICAgICAgW1N5c3RlbSBleHRlbnNpb24gZm9yIGR5bmFtaWMg bGlicmFyaWVzXSkKQEAgLTM3ODUsNyArMzc4Nyw2IEBAIEFDX0RFRlVOCiAKIEhBVkVfTkFUSVZF X0NPTVA9bm8KIExJQkdDQ0pJVF9MSUI9Ci1DT01QX09CSj0KIGlmIHRlc3QgIiR7d2l0aF9uYXRp dmVjb21wfSIgIT0gIm5vIjsgdGhlbgogICAgIGVtYWNzX3NhdmVfTElCUz0kTElCUwogICAgIExJ QlM9Ii1sZ2Njaml0IgpAQCAtMzc5Myw4ICszNzk0LDExIEBAIEFDX0RFRlVOCiAgICAgICBbQUNf TElOS19JRkVMU0UoW2xpYmdjY2ppdF9zbW9rZV90ZXN0XSwgW10sIFtsaWJnY2NqaXRfbm90X2Zv dW5kXSldKQogICAgIExJQlM9JGVtYWNzX3NhdmVfTElCUwogICAgIEhBVkVfTkFUSVZFX0NPTVA9 eWVzCi0gICAgTElCR0NDSklUX0xJQj0iLWxnY2NqaXQgLWxkbCIKLSAgICBDT01QX09CSj0iY29t cC5vIgorICAgICMgbWluZ3czMiBsb2FkcyB0aGUgbGlicmFyeSBkeW5hbWljYWxseS4KKyAgICBp ZiB0ZXN0ICIke29wc3lzfSIgIT0gIm1pbmd3MzIiOyB0aGVuCisgICAgICBMSUJHQ0NKSVRfTElC PSItbGdjY2ppdCAtbGRsIgorICAgIGZpCisgICAgTkVFRF9EWU5MSUI9eWVzCiAgICAgQUNfREVG SU5FKEhBVkVfTkFUSVZFX0NPTVAsIDEsIFtEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgbGli Z2Njaml0IGxpYnJhcnkgKC1sZ2Njaml0KS5dKQogZmkKIGlmIHRlc3QgIiR7SEFWRV9OQVRJVkVf Q09NUH0iID0geWVzICYmIHRlc3QgIiR7SEFWRV9QRFVNUEVSfSIgPSBubzsgdGhlbgpAQCAtMzgw NCw3ICszODA4LDEyIEBAIEFDX0RFRlVOCiAgIFtTeXN0ZW0gZXh0ZW5zaW9uIGZvciBuYXRpdmUg Y29tcGlsZWQgZWxpc3BdKQogQUNfU1VCU1QoSEFWRV9OQVRJVkVfQ09NUCkKIEFDX1NVQlNUKExJ QkdDQ0pJVF9MSUIpCi1BQ19TVUJTVChDT01QX09CSikKKworRFlOTElCX09CSj0KK2lmIHRlc3Qg IiR7TkVFRF9EWU5MSUJ9IiA9IHllczsgdGhlbgorICBEWU5MSUJfT0JKPSJkeW5saWIubyIKK2Zp CitBQ19TVUJTVChEWU5MSUJfT0JKKQogCiAjIyMgVXNlIC1scG5nIGlmIGF2YWlsYWJsZSwgdW5s ZXNzICctLXdpdGgtcG5nPW5vJy4KIEhBVkVfUE5HPW5vCmRpZmYgLS1naXQgYS9saXNwL3Rlcm0v dzMyLXdpbi5lbCBiL2xpc3AvdGVybS93MzItd2luLmVsCmluZGV4IDU5MDFlMDI5NWUuLjZiOTcx NmNhMzAgMTAwNjQ0Ci0tLSBhL2xpc3AvdGVybS93MzItd2luLmVsCisrKyBiL2xpc3AvdGVybS93 MzItd2luLmVsCkBAIC0yODksNyArMjg5LDggQEAgbGliZ251dGxzLXZlcnNpb24KICAgICAgICAn KGxpYnhtbDIgImxpYnhtbDItMi5kbGwiICJsaWJ4bWwyLmRsbCIpCiAgICAgICAgJyh6bGliICJ6 bGliMS5kbGwiICJsaWJ6LTEuZGxsIikKICAgICAgICAnKGxjbXMyICJsaWJsY21zMi0yLmRsbCIp Ci0gICAgICAgJyhqc29uICJsaWJqYW5zc29uLTQuZGxsIikpKQorICAgICAgICcoanNvbiAibGli amFuc3Nvbi00LmRsbCIpCisgICAgICAgJyhnY2NqaXQgImxpYmdjY2ppdC5kbGwiKSkpCiAKIDs7 OyBtdWx0aS10dHkgc3VwcG9ydAogKGRlZnZhciB3MzItaW5pdGlhbGl6ZWQgbmlsCmRpZmYgLS1n aXQgYS9zcmMvTWFrZWZpbGUuaW4gYi9zcmMvTWFrZWZpbGUuaW4KaW5kZXggNjNmOTA5YWUxNC4u ODU3MDkxODRkYSAxMDA2NDQKLS0tIGEvc3JjL01ha2VmaWxlLmluCisrKyBiL3NyYy9NYWtlZmls ZS5pbgpAQCAtMjQxLDcgKzI0MSw3IEBAIExJQlogPQogCiAjIyBzeXN0ZW0tc3BlY2lmaWMgbGli cyBmb3IgZHluYW1pYyBtb2R1bGVzLCBlbHNlIGVtcHR5CiBMSUJNT0RVTEVTID0gQExJQk1PRFVM RVNACi0jIyBkeW5saWIubyBlbWFjcy1tb2R1bGUubyBpZiBtb2R1bGVzIGVuYWJsZWQsIGVsc2Ug ZW1wdHkKKyMjIGVtYWNzLW1vZHVsZS5vIGlmIG1vZHVsZXMgZW5hYmxlZCwgZWxzZSBlbXB0eQog TU9EVUxFU19PQkogPSBATU9EVUxFU19PQkpACiAKIFhSQU5EUl9MSUJTID0gQFhSQU5EUl9MSUJT QApAQCAtMzI3LDggKzMyNyw5IEBAIEdNUF9MSUIgPQogR01QX09CSiA9IEBHTVBfT0JKQAogCiBM SUJHQ0NKSVQgPSBATElCR0NDSklUX0xJQkAKLSMjIGR5bmxpYi5vIGNvbXAubyBpZiBuYXRpdmUg Y29tcGlsZXIgaXMgZW5hYmxlZCwgb3RoZXJ3aXNlIGVtcHR5LgotQ09NUF9PQkogPSBAQ09NUF9P QkpACisKKyMjIGR5bmxpYi5vIGlmIG5lY2Vzc2FyeSwgZWxzZSBlbXB0eQorRFlOTElCX09CSiA9 IEBEWU5MSUJfT0JKQAogCiBSVU5fVEVNQUNTID0gLi90ZW1hY3MKIApAQCAtNDE4LDcgKzQxOSw3 IEBAIGJhc2Vfb2JqID0KIAljbWRzLm8gY2FzZXRhYi5vIGNhc2VmaWRkbGUubyBpbmRlbnQubyBz ZWFyY2gubyByZWdleC1lbWFjcy5vIHVuZG8ubyBcCiAJYWxsb2MubyBwZHVtcGVyLm8gZGF0YS5v IGRvYy5vIGVkaXRmbnMubyBjYWxsaW50Lm8gXAogCWV2YWwubyBmbG9hdGZucy5vIGZucy5vIGZv bnQubyBwcmludC5vIGxyZWFkLm8gJChNT0RVTEVTX09CSikgXAotCXN5bnRheC5vICQoVU5FWEVD X09CSikgYnl0ZWNvZGUubyAkKENPTVBfT0JKKSBcCisJc3ludGF4Lm8gJChVTkVYRUNfT0JKKSBi eXRlY29kZS5vIGNvbXAubyAkKERZTkxJQl9PQkopIFwKIAlwcm9jZXNzLm8gZ251dGxzLm8gY2Fs bHByb2MubyBcCiAJcmVnaW9uLWNhY2hlLm8gc291bmQubyB0aW1lZm5zLm8gYXRpbWVyLm8gXAog CWRvcHJudC5vIGludGVydmFscy5vIHRleHRwcm9wLm8gY29tcG9zaXRlLm8geG1sLm8gbGNtcy5v ICQoTk9USUZZX09CSikgXApkaWZmIC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9jb21wLmMKaW5k ZXggNjk1MjVhY2ZjMC4uYjQzZDNlZGRiMyAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9z cmMvY29tcC5jCkBAIC0yMCw2ICsyMCw4IEBACiAKICNpbmNsdWRlIDxjb25maWcuaD4KIAorI2lu Y2x1ZGUgImxpc3AuaCIKKwogI2lmZGVmIEhBVkVfTkFUSVZFX0NPTVAKIAogI2luY2x1ZGUgPHNl dGptcC5oPgpAQCAtMjgsNyArMzAsNiBAQAogI2luY2x1ZGUgPHNpZ25hbC5oPgogI2luY2x1ZGUg PGxpYmdjY2ppdC5oPgogCi0jaW5jbHVkZSAibGlzcC5oIgogI2luY2x1ZGUgInB1cmVzaXplLmgi CiAjaW5jbHVkZSAid2luZG93LmgiCiAjaW5jbHVkZSAiZHlubGliLmgiCkBAIC0zNiw2ICszNywz NDcgQEAKICNpbmNsdWRlICJibG9ja2lucHV0LmgiCiAjaW5jbHVkZSAic2hhNTEyLmgiCiAKKwwK Ky8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKy8qIER5bmFtaWMgbG9hZGluZyBv ZiBsaWJnY2NqaXQgKi8KKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworI2lm ZGVmIFdJTkRPV1NOVAorIyBpbmNsdWRlICJ3MzJjb21tb24uaCIKKworI3VuZGVmIGdjY19qaXRf YmxvY2tfYWRkX2Fzc2lnbm1lbnQKKyN1bmRlZiBnY2Nfaml0X2Jsb2NrX2FkZF9jb21tZW50Cisj dW5kZWYgZ2NjX2ppdF9ibG9ja19hZGRfZXZhbAorI3VuZGVmIGdjY19qaXRfYmxvY2tfZW5kX3dp dGhfY29uZGl0aW9uYWwKKyN1bmRlZiBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2p1bXAKKyN1bmRl ZiBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX3JldHVybgorI3VuZGVmIGdjY19qaXRfYmxvY2tfZW5k X3dpdGhfdm9pZF9yZXR1cm4KKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZQorI3VuZGVm IGdjY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRf ZHVtcF9yZXByb2R1Y2VyX3RvX2ZpbGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfZHVtcF90b19m aWxlCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X2dldF9idWlsdGluX2Z1bmN0aW9uCisjdW5kZWYg Z2NjX2ppdF9jb250ZXh0X2dldF9maXJzdF9lcnJvcgorI3VuZGVmIGdjY19qaXRfY29udGV4dF9n ZXRfaW50X3R5cGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUKKyN1bmRlZiBnY2Nf aml0X2NvbnRleHRfbmV3X2FycmF5X2FjY2VzcworI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdf YXJyYXlfdHlwZQorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdfYmluYXJ5X29wCisjdW5kZWYg Z2NjX2ppdF9jb250ZXh0X25ld19jYWxsCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19jYWxs X3Rocm91Z2hfcHRyCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19jb21wYXJpc29uCisjdW5k ZWYgZ2NjX2ppdF9jb250ZXh0X25ld19maWVsZAorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdf ZnVuY3Rpb24KKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uX3B0cl90eXBlCisj dW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19nbG9iYWwKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRf bmV3X29wYXF1ZV9zdHJ1Y3QKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3BhcmFtCisjdW5k ZWYgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQKKyN1bmRlZiBnY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3J2 YWx1ZV9mcm9tX3B0cgorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdfc3RydWN0X3R5cGUKKyN1 bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3VuYXJ5X29wCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0 X25ld191bmlvbl90eXBlCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3JlbGVhc2UKKyN1bmRlZiBn Y2Nfaml0X2NvbnRleHRfc2V0X2Jvb2xfb3B0aW9uCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3Nl dF9pbnRfb3B0aW9uCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3NldF9sb2dmaWxlCisjdW5kZWYg Z2NjX2ppdF9mdW5jdGlvbl9nZXRfcGFyYW0KKyN1bmRlZiBnY2Nfaml0X2Z1bmN0aW9uX25ld19i bG9jaworI3VuZGVmIGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsCisjdW5kZWYgZ2NjX2ppdF9s dmFsdWVfYWNjZXNzX2ZpZWxkCisjdW5kZWYgZ2NjX2ppdF9sdmFsdWVfYXNfcnZhbHVlCisjdW5k ZWYgZ2NjX2ppdF9sdmFsdWVfZ2V0X2FkZHJlc3MKKyN1bmRlZiBnY2Nfaml0X3BhcmFtX2FzX2x2 YWx1ZQorI3VuZGVmIGdjY19qaXRfcGFyYW1fYXNfcnZhbHVlCisjdW5kZWYgZ2NjX2ppdF9ydmFs dWVfYWNjZXNzX2ZpZWxkCisjdW5kZWYgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2UKKyN1bmRl ZiBnY2Nfaml0X3J2YWx1ZV9kZXJlZmVyZW5jZV9maWVsZAorI3VuZGVmIGdjY19qaXRfcnZhbHVl X2dldF90eXBlCisjdW5kZWYgZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZQorI3VuZGVmIGdjY19qaXRf c3RydWN0X3NldF9maWVsZHMKKyN1bmRlZiBnY2Nfaml0X3R5cGVfZ2V0X3BvaW50ZXIKKworLyog SW4gYWxwaGFiZXRpY2FsIG9yZGVyICovCitERUZfRExMX0ZOIChnY2Nfaml0X3J2YWx1ZSAqLCBn Y2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCwKKyAgICAgICAgICAgIChnY2Nfaml0 X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfdHlwZSAqbnVtZXJpY190eXBlLCBpbnQgdmFsdWUpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfbHZhbHVlX2FzX3J2YWx1ZSwK KyAgICAgICAgICAgIChnY2Nfaml0X2x2YWx1ZSAqbHZhbHVlKSk7CitERUZfRExMX0ZOIChnY2Nf aml0X3J2YWx1ZSAqLCBnY2Nfaml0X3J2YWx1ZV9hY2Nlc3NfZmllbGQsCisgICAgICAgICAgICAo Z2NjX2ppdF9ydmFsdWUgKnN0cnVjdF9vcl91bmlvbiwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAor ICAgICAgICAgICAgIGdjY19qaXRfZmllbGQgKmZpZWxkKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2FkZF9jb21tZW50LAorICAgICAgICAgICAgKGdjY19qaXRfYmxvY2sgKmJs b2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsIGNvbnN0IGNoYXIgKnRleHQpKTsKK0RFRl9ETExf Rk4gKHZvaWQsIGdjY19qaXRfY29udGV4dF9yZWxlYXNlLCAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0 KSk7CitERUZfRExMX0ZOIChjb25zdCBjaGFyICosIGdjY19qaXRfY29udGV4dF9nZXRfZmlyc3Rf ZXJyb3IsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0KSk7CitERUZfRExMX0ZO IChnY2Nfaml0X2Jsb2NrICosIGdjY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrLAorICAgICAgICAg ICAgKGdjY19qaXRfZnVuY3Rpb24gKmZ1bmMsIGNvbnN0IGNoYXIgKm5hbWUpKTsKK0RFRl9ETExf Rk4gKGdjY19qaXRfY29udGV4dCAqLCBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZSwgKHZvaWQpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfZmllbGQgKiwgZ2NjX2ppdF9jb250ZXh0X25ld19maWVsZCwK KyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxv YywgZ2NjX2ppdF90eXBlICp0eXBlLAorICAgICAgICAgICAgIGNvbnN0IGNoYXIgKm5hbWUpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfZnVuY3Rpb24gKiwgZ2NjX2ppdF9jb250ZXh0X2dldF9idWls dGluX2Z1bmN0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgY29uc3Qg Y2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9mdW5jdGlvbiAqLCBnY2Nfaml0X2Nv bnRleHRfbmV3X2Z1bmN0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwg Z2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGVudW0gZ2NjX2ppdF9mdW5jdGlv bl9raW5kIGtpbmQsIGdjY19qaXRfdHlwZSAqcmV0dXJuX3R5cGUsCisgICAgICAgICAgICAgY29u c3QgY2hhciAqbmFtZSwgaW50IG51bV9wYXJhbXMsIGdjY19qaXRfcGFyYW0gKipwYXJhbXMsCisg ICAgICAgICAgICAgaW50IGlzX3ZhcmlhZGljKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X2x2YWx1 ZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X2FjY2VzcywKKyAgICAgICAgICAgIChnY2Nf aml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxvYywgZ2NjX2ppdF9ydmFsdWUg KnB0ciwKKyAgICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqaW5kZXgpKTsKK0RFRl9ETExfRk4g KGdjY19qaXRfbHZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfZ2xvYmFsLAorICAgICAgICAg ICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAg ICAgICAgIGVudW0gZ2NjX2ppdF9nbG9iYWxfa2luZCBraW5kLCBnY2Nfaml0X3R5cGUgKnR5cGUs CisgICAgICAgICAgICAgY29uc3QgY2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9s dmFsdWUgKiwgZ2NjX2ppdF9mdW5jdGlvbl9uZXdfbG9jYWwsCisgICAgICAgICAgICAoZ2NjX2pp dF9mdW5jdGlvbiAqZnVuYywgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLCBnY2Nfaml0X3R5cGUgKnR5 cGUsCisgICAgICAgICAgICAgY29uc3QgY2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2pp dF9sdmFsdWUgKiwgZ2NjX2ppdF9sdmFsdWVfYWNjZXNzX2ZpZWxkLAorICAgICAgICAgICAgKGdj Y19qaXRfbHZhbHVlICpzdHJ1Y3Rfb3JfdW5pb24sIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X2ZpZWxkICpmaWVsZCkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9s dmFsdWUgKiwgZ2NjX2ppdF9wYXJhbV9hc19sdmFsdWUsIChnY2Nfaml0X3BhcmFtICpwYXJhbSkp OworREVGX0RMTF9GTiAoZ2NjX2ppdF9sdmFsdWUgKiwgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVu Y2UsCisgICAgICAgICAgICAoZ2NjX2ppdF9ydmFsdWUgKnJ2YWx1ZSwgZ2NjX2ppdF9sb2NhdGlv biAqbG9jKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X2x2YWx1ZSAqLCBnY2Nfaml0X3J2YWx1ZV9k ZXJlZmVyZW5jZV9maWVsZCwKKyAgICAgICAgICAgIChnY2Nfaml0X3J2YWx1ZSAqcHRyLCBnY2Nf aml0X2xvY2F0aW9uICpsb2MsIGdjY19qaXRfZmllbGQgKmZpZWxkKSk7CitERUZfRExMX0ZOIChn Y2Nfaml0X3BhcmFtICosIGdjY19qaXRfY29udGV4dF9uZXdfcGFyYW0sCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsIGdjY19qaXRfdHlw ZSAqdHlwZSwKKyAgICAgICAgICAgICBjb25zdCBjaGFyICpuYW1lKSk7CitERUZfRExMX0ZOIChn Y2Nfaml0X3BhcmFtICosIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtLAorICAgICAgICAgICAg KGdjY19qaXRfZnVuY3Rpb24gKmZ1bmMsIGludCBpbmRleCkpOworREVGX0RMTF9GTiAoZ2NjX2pp dF9ydmFsdWUgKiwgZ2NjX2ppdF9jb250ZXh0X25ld19iaW5hcnlfb3AsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAg ICAgZW51bSBnY2Nfaml0X2JpbmFyeV9vcCBvcCwgZ2NjX2ppdF90eXBlICpyZXN1bHRfdHlwZSwK KyAgICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF9ydmFsdWUgKmIpKTsKK0RF Rl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbCwKKyAg ICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxvYywK KyAgICAgICAgICAgICBnY2Nfaml0X2Z1bmN0aW9uICpmdW5jLCBpbnQgbnVtYXJncyAsIGdjY19q aXRfcnZhbHVlICoqYXJncykpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2pp dF9jb250ZXh0X25ld19jYWxsX3Rocm91Z2hfcHRyLAorICAgICAgICAgICAgKGdjY19qaXRfY29u dGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRf cnZhbHVlICpmbl9wdHIsIGludCBudW1hcmdzLCBnY2Nfaml0X3J2YWx1ZSAqKmFyZ3MpKTsKK0RF Rl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfY29tcGFyaXNv biwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24g KmxvYywKKyAgICAgICAgICAgICBlbnVtIGdjY19qaXRfY29tcGFyaXNvbiBvcCwgZ2NjX2ppdF9y dmFsdWUgKmEsIGdjY19qaXRfcnZhbHVlICpiKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X3J2YWx1 ZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X3R5cGUgKm51bWVyaWNfdHlwZSwgbG9uZyB2 YWx1ZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2ppdF9jb250ZXh0X25l d19ydmFsdWVfZnJvbV9wdHIsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBn Y2Nfaml0X3R5cGUgKnBvaW50ZXJfdHlwZSwgdm9pZCAqdmFsdWUpKTsKK0RFRl9ETExfRk4gKGdj Y19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfdW5hcnlfb3AsCisgICAgICAgICAg ICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAg ICAgICAgZW51bSBnY2Nfaml0X3VuYXJ5X29wIG9wLCBnY2Nfaml0X3R5cGUgKnJlc3VsdF90eXBl LAorICAgICAgICAgICAgIGdjY19qaXRfcnZhbHVlICpydmFsdWUpKTsKK0RFRl9ETExfRk4gKGdj Y19qaXRfcnZhbHVlICosIGdjY19qaXRfbHZhbHVlX2dldF9hZGRyZXNzLAorICAgICAgICAgICAg KGdjY19qaXRfbHZhbHVlICpsdmFsdWUsIGdjY19qaXRfbG9jYXRpb24gKmxvYykpOworREVGX0RM TF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2ppdF9wYXJhbV9hc19ydmFsdWUsIChnY2Nfaml0 X3BhcmFtICpwYXJhbSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9zdHJ1Y3QgKiwgZ2NjX2ppdF9j b250ZXh0X25ld19vcGFxdWVfc3RydWN0LAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAq Y3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLCBjb25zdCBjaGFyICpuYW1lKSk7CitERUZfRExM X0ZOIChnY2Nfaml0X3N0cnVjdCAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X3N0cnVjdF90eXBlLAor ICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9j LCBjb25zdCBjaGFyICpuYW1lLAorICAgICAgICAgICAgIGludCBudW1fZmllbGRzLCBnY2Nfaml0 X2ZpZWxkICoqZmllbGRzKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X3R5cGUgKiwgZ2NjX2ppdF9j b250ZXh0X2dldF9pbnRfdHlwZSwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQs IGludCBudW1fYnl0ZXMsIGludCBpc19zaWduZWQpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlw ZSAqLCBnY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250 ZXh0ICpjdHh0LCBlbnVtIGdjY19qaXRfdHlwZXMgdHlwZV8pKTsKK0RFRl9ETExfRk4gKGdjY19q aXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X3R5cGUsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAg ICAgZ2NjX2ppdF90eXBlICplbGVtZW50X3R5cGUsIGludCBudW1fZWxlbWVudHMpKTsKK0RFRl9E TExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uX3B0cl90 eXBlLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlv biAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRfdHlwZSAqcmV0dXJuX3R5cGUsIGludCBudW1f cGFyYW1zLAorICAgICAgICAgICAgIGdjY19qaXRfdHlwZSAqKnBhcmFtX3R5cGVzLCBpbnQgaXNf dmFyaWFkaWMpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRf bmV3X3VuaW9uX3R5cGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nf aml0X2xvY2F0aW9uICpsb2MsIGNvbnN0IGNoYXIgKm5hbWUsCisgICAgICAgICAgICAgaW50IG51 bV9maWVsZHMsIGdjY19qaXRfZmllbGQgKipmaWVsZHMpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRf dHlwZSAqLCBnY2Nfaml0X3J2YWx1ZV9nZXRfdHlwZSwgKGdjY19qaXRfcnZhbHVlICpydmFsdWUp KTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X3N0cnVjdF9hc190eXBlLAor ICAgICAgICAgICAgKGdjY19qaXRfc3RydWN0ICpzdHJ1Y3RfdHlwZSkpOworREVGX0RMTF9GTiAo Z2NjX2ppdF90eXBlICosIGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciwgKGdjY19qaXRfdHlwZSAq dHlwZSkpOworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9ibG9ja19hZGRfYXNzaWdubWVudCwK KyAgICAgICAgICAgIChnY2Nfaml0X2Jsb2NrICpibG9jaywgZ2NjX2ppdF9sb2NhdGlvbiAqbG9j LCBnY2Nfaml0X2x2YWx1ZSAqbHZhbHVlLAorICAgICAgICAgICAgIGdjY19qaXRfcnZhbHVlICpy dmFsdWUpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRfYmxvY2tfYWRkX2V2YWwsCisgICAg ICAgICAgICAoZ2NjX2ppdF9ibG9jayAqYmxvY2ssIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqcnZhbHVlKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2VuZF93aXRoX2NvbmRpdGlvbmFsLAorICAgICAgICAgICAgKGdjY19qaXRf YmxvY2sgKmJsb2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAgICAgZ2NjX2pp dF9ydmFsdWUgKmJvb2x2YWwsIGdjY19qaXRfYmxvY2sgKm9uX3RydWUsCisgICAgICAgICAgICAg Z2NjX2ppdF9ibG9jayAqb25fZmFsc2UpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRfYmxv Y2tfZW5kX3dpdGhfanVtcCwKKyAgICAgICAgICAgIChnY2Nfaml0X2Jsb2NrICpibG9jaywgZ2Nj X2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRfYmxvY2sgKnRhcmdldCkp OworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9yZXR1cm4sCisgICAg ICAgICAgICAoZ2NjX2ppdF9ibG9jayAqYmxvY2ssIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqcnZhbHVlKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2VuZF93aXRoX3ZvaWRfcmV0dXJuLAorICAgICAgICAgICAgKGdjY19qaXRf YmxvY2sgKmJsb2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MpKTsKK0RFRl9ETExfRk4gKHZvaWQs IGdjY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9j b250ZXh0ICpjdHh0LCBlbnVtIGdjY19qaXRfb3V0cHV0X2tpbmQgb3V0cHV0X2tpbmQsCisgICAg ICAgICAgICAgY29uc3QgY2hhciAqb3V0cHV0X3BhdGgpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdj Y19qaXRfY29udGV4dF9kdW1wX3JlcHJvZHVjZXJfdG9fZmlsZSwKKyAgICAgICAgICAgIChnY2Nf aml0X2NvbnRleHQgKmN0eHQsIGNvbnN0IGNoYXIgKnBhdGgpKTsKK0RFRl9ETExfRk4gKHZvaWQs IGdjY19qaXRfY29udGV4dF9kdW1wX3RvX2ZpbGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250 ZXh0ICpjdHh0LCBjb25zdCBjaGFyICpwYXRoLCBpbnQgdXBkYXRlX2xvY2F0aW9ucykpOworREVG X0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9jb250ZXh0X3NldF9ib29sX29wdGlvbiwKKyAgICAgICAg ICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGVudW0gZ2NjX2ppdF9ib29sX29wdGlvbiBvcHQs IGludCB2YWx1ZSkpOworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9jb250ZXh0X3NldF9pbnRf b3B0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZW51bSBnY2Nfaml0 X2ludF9vcHRpb24gb3B0LCBpbnQgdmFsdWUpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRf Y29udGV4dF9zZXRfbG9nZmlsZSwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQs IEZJTEUgKmxvZ2ZpbGUsIGludCBmbGFncywgaW50IHZlcmJvc2l0eSkpOworREVGX0RMTF9GTiAo dm9pZCwgZ2NjX2ppdF9zdHJ1Y3Rfc2V0X2ZpZWxkcywKKyAgICAgICAgICAgIChnY2Nfaml0X3N0 cnVjdCAqc3RydWN0X3R5cGUsIGdjY19qaXRfbG9jYXRpb24gKmxvYywgaW50IG51bV9maWVsZHMs CisgICAgICAgICAgICAgZ2NjX2ppdF9maWVsZCAqKmZpZWxkcykpOworCitzdGF0aWMgYm9vbAor aW5pdF9nY2NqaXRfZnVuY3Rpb25zICh2b2lkKQoreworICBITU9EVUxFIGxpYnJhcnk7CisKKyAg aWYgKCEobGlicmFyeSA9IHczMl9kZWxheWVkX2xvYWQgKFFnY2NqaXQpKSkKKyAgICB7CisgICAg ICByZXR1cm4gZmFsc2U7CisgICAgfQorCisgIC8qIEluIGFscGhhYmV0aWNhbCBvcmRlciAqLwor ICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2FkZF9hc3NpZ25tZW50KTsKKyAg TE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9ibG9ja19hZGRfY29tbWVudCk7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfYmxvY2tfYWRkX2V2YWwpOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2NvbmRpdGlvbmFsKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9qdW1wKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9yZXR1cm4pOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX3ZvaWRfcmV0dXJuKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2FjcXVpcmUpOworICBMT0FEX0RMTF9GTihsaWJy YXJ5LCBnY2Nfaml0X2NvbnRleHRfY29tcGlsZV90b19maWxlKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF9jb250ZXh0X2R1bXBfcmVwcm9kdWNlcl90b19maWxlKTsKKyAgTE9BRF9E TExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2R1bXBfdG9fZmlsZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9nZXRfYnVpbHRpbl9mdW5jdGlvbik7CisgIExP QURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9nZXRfZmlyc3RfZXJyb3IpOworICBM T0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfZ2V0X2ludF90eXBlKTsKKyAgTE9B RF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2dldF90eXBlKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV9hY2Nlc3MpOworICBMT0FEX0RM TF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X3R5cGUpOworICBMT0FEX0RM TF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcCk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbCk7CisgIExPQURfRExMX0ZOKGxp YnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbF90aHJvdWdoX3B0cik7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY29tcGFyaXNvbik7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQpOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19mdW5jdGlvbl9wdHJfdHlwZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfZ2xvYmFsKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19vcGFxdWVfc3RydWN0KTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19wYXJhbSk7CisgIExPQURfRExMX0ZOKGxp YnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21faW50KTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9sb25nKTsKKyAgTE9B RF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9wdHIpOwor ICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X3N0cnVjdF90eXBlKTsK KyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld191bmFyeV9vcCk7Cisg IExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfdW5pb25fdHlwZSk7Cisg IExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9yZWxlYXNlKTsKKyAgTE9BRF9E TExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X3NldF9ib29sX29wdGlvbik7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9zZXRfaW50X29wdGlvbik7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9zZXRfbG9nZmlsZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9mdW5jdGlvbl9uZXdfYmxvY2spOworICBMT0FEX0RMTF9GTihsaWJy YXJ5LCBnY2Nfaml0X2Z1bmN0aW9uX25ld19sb2NhbCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnks IGdjY19qaXRfbHZhbHVlX2FjY2Vzc19maWVsZCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdj Y19qaXRfbHZhbHVlX2FzX3J2YWx1ZSk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRf bHZhbHVlX2dldF9hZGRyZXNzKTsKKyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9wYXJh bV9hc19sdmFsdWUpOworICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X3BhcmFtX2FzX3J2 YWx1ZSk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfcnZhbHVlX2FjY2Vzc19maWVs ZCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlKTsK KyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2VfZmllbGQp OworICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X3J2YWx1ZV9nZXRfdHlwZSk7CisgIExP QURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfc3RydWN0X2FzX3R5cGUpOworICBMT0FEX0RMTF9G TihsaWJyYXJ5LCBnY2Nfaml0X3N0cnVjdF9zZXRfZmllbGRzKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyKTsKKworICByZXR1cm4gdHJ1ZTsKK30KKwor LyogSW4gYWxwaGFiZXRpY2FsIG9yZGVyICovCisjZGVmaW5lIGdjY19qaXRfYmxvY2tfYWRkX2Fz c2lnbm1lbnQgZm5fZ2NjX2ppdF9ibG9ja19hZGRfYXNzaWdubWVudAorI2RlZmluZSBnY2Nfaml0 X2Jsb2NrX2FkZF9jb21tZW50IGZuX2djY19qaXRfYmxvY2tfYWRkX2NvbW1lbnQKKyNkZWZpbmUg Z2NjX2ppdF9ibG9ja19hZGRfZXZhbCBmbl9nY2Nfaml0X2Jsb2NrX2FkZF9ldmFsCisjZGVmaW5l IGdjY19qaXRfYmxvY2tfZW5kX3dpdGhfY29uZGl0aW9uYWwgZm5fZ2NjX2ppdF9ibG9ja19lbmRf d2l0aF9jb25kaXRpb25hbAorI2RlZmluZSBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2p1bXAgZm5f Z2NjX2ppdF9ibG9ja19lbmRfd2l0aF9qdW1wCisjZGVmaW5lIGdjY19qaXRfYmxvY2tfZW5kX3dp dGhfcmV0dXJuIGZuX2djY19qaXRfYmxvY2tfZW5kX3dpdGhfcmV0dXJuCisjZGVmaW5lIGdjY19q aXRfYmxvY2tfZW5kX3dpdGhfdm9pZF9yZXR1cm4gZm5fZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF92 b2lkX3JldHVybgorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZSBmbl9nY2Nfaml0X2Nv bnRleHRfYWNxdWlyZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfY29tcGlsZV90b19maWxlIGZu X2djY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0 X2R1bXBfcmVwcm9kdWNlcl90b19maWxlIGZuX2djY19qaXRfY29udGV4dF9kdW1wX3JlcHJvZHVj ZXJfdG9fZmlsZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfZHVtcF90b19maWxlIGZuX2djY19q aXRfY29udGV4dF9kdW1wX3RvX2ZpbGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X2dldF9idWls dGluX2Z1bmN0aW9uIGZuX2djY19qaXRfY29udGV4dF9nZXRfYnVpbHRpbl9mdW5jdGlvbgorI2Rl ZmluZSBnY2Nfaml0X2NvbnRleHRfZ2V0X2ZpcnN0X2Vycm9yIGZuX2djY19qaXRfY29udGV4dF9n ZXRfZmlyc3RfZXJyb3IKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X2dldF9pbnRfdHlwZSBmbl9n Y2Nfaml0X2NvbnRleHRfZ2V0X2ludF90eXBlCisjZGVmaW5lIGdjY19qaXRfY29udGV4dF9nZXRf dHlwZSBmbl9nY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0 X25ld19hcnJheV9hY2Nlc3MgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV9hY2Nlc3MKKyNk ZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV90eXBlIGZuX2djY19qaXRfY29udGV4dF9u ZXdfYXJyYXlfdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcCBmbl9n Y2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3 X2NhbGwgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19jYWxsCisjZGVmaW5lIGdjY19qaXRfY29udGV4 dF9uZXdfY2FsbF90aHJvdWdoX3B0ciBmbl9nY2Nfaml0X2NvbnRleHRfbmV3X2NhbGxfdGhyb3Vn aF9wdHIKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld19jb21wYXJpc29uIGZuX2djY19qaXRf Y29udGV4dF9uZXdfY29tcGFyaXNvbgorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2ZpZWxk IGZuX2djY19qaXRfY29udGV4dF9uZXdfZmllbGQKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25l d19mdW5jdGlvbiBmbl9nY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uCisjZGVmaW5lIGdjY19q aXRfY29udGV4dF9uZXdfZnVuY3Rpb25fcHRyX3R5cGUgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19m dW5jdGlvbl9wdHJfdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2dsb2JhbCBmbl9n Y2Nfaml0X2NvbnRleHRfbmV3X2dsb2JhbAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X29w YXF1ZV9zdHJ1Y3QgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19vcGFxdWVfc3RydWN0CisjZGVmaW5l IGdjY19qaXRfY29udGV4dF9uZXdfcGFyYW0gZm5fZ2NjX2ppdF9jb250ZXh0X25ld19wYXJhbQor I2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCBmbl9nY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X3J2 YWx1ZV9mcm9tX2xvbmcgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9sb25nCisj ZGVmaW5lIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIGZuX2djY19qaXRfY29u dGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyCisjZGVmaW5lIGdjY19qaXRfY29udGV4dF9uZXdfc3Ry dWN0X3R5cGUgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfdHlwZQorI2RlZmluZSBnY2Nf aml0X2NvbnRleHRfbmV3X3VuYXJ5X29wIGZuX2djY19qaXRfY29udGV4dF9uZXdfdW5hcnlfb3AK KyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld191bmlvbl90eXBlIGZuX2djY19qaXRfY29udGV4 dF9uZXdfdW5pb25fdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfcmVsZWFzZSBmbl9nY2Nf aml0X2NvbnRleHRfcmVsZWFzZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfc2V0X2Jvb2xfb3B0 aW9uIGZuX2djY19qaXRfY29udGV4dF9zZXRfYm9vbF9vcHRpb24KKyNkZWZpbmUgZ2NjX2ppdF9j b250ZXh0X3NldF9pbnRfb3B0aW9uIGZuX2djY19qaXRfY29udGV4dF9zZXRfaW50X29wdGlvbgor I2RlZmluZSBnY2Nfaml0X2NvbnRleHRfc2V0X2xvZ2ZpbGUgZm5fZ2NjX2ppdF9jb250ZXh0X3Nl dF9sb2dmaWxlCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtIGZuX2djY19qaXRf ZnVuY3Rpb25fZ2V0X3BhcmFtCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrIGZu X2djY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fbmV3 X2xvY2FsIGZuX2djY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsCisjZGVmaW5lIGdjY19qaXRfbHZh bHVlX2FjY2Vzc19maWVsZCBmbl9nY2Nfaml0X2x2YWx1ZV9hY2Nlc3NfZmllbGQKKyNkZWZpbmUg Z2NjX2ppdF9sdmFsdWVfYXNfcnZhbHVlIGZuX2djY19qaXRfbHZhbHVlX2FzX3J2YWx1ZQorI2Rl ZmluZSBnY2Nfaml0X2x2YWx1ZV9nZXRfYWRkcmVzcyBmbl9nY2Nfaml0X2x2YWx1ZV9nZXRfYWRk cmVzcworI2RlZmluZSBnY2Nfaml0X3BhcmFtX2FzX2x2YWx1ZSBmbl9nY2Nfaml0X3BhcmFtX2Fz X2x2YWx1ZQorI2RlZmluZSBnY2Nfaml0X3BhcmFtX2FzX3J2YWx1ZSBmbl9nY2Nfaml0X3BhcmFt X2FzX3J2YWx1ZQorI2RlZmluZSBnY2Nfaml0X3J2YWx1ZV9hY2Nlc3NfZmllbGQgZm5fZ2NjX2pp dF9ydmFsdWVfYWNjZXNzX2ZpZWxkCisjZGVmaW5lIGdjY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNl IGZuX2djY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlCisjZGVmaW5lIGdjY19qaXRfcnZhbHVlX2Rl cmVmZXJlbmNlX2ZpZWxkIGZuX2djY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlX2ZpZWxkCisjZGVm aW5lIGdjY19qaXRfcnZhbHVlX2dldF90eXBlIGZuX2djY19qaXRfcnZhbHVlX2dldF90eXBlCisj ZGVmaW5lIGdjY19qaXRfc3RydWN0X2FzX3R5cGUgZm5fZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZQor I2RlZmluZSBnY2Nfaml0X3N0cnVjdF9zZXRfZmllbGRzIGZuX2djY19qaXRfc3RydWN0X3NldF9m aWVsZHMKKyNkZWZpbmUgZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyIGZuX2djY19qaXRfdHlwZV9n ZXRfcG9pbnRlcgorCisjZW5kaWYKKworc3RhdGljIGJvb2wKK2xvYWRfZ2Njaml0X2lmX25lY2Vz c2FyeSAoYm9vbCBtYW5kYXRvcnkpCit7CisjaWZkZWYgV0lORE9XU05UCisgIHN0YXRpYyBib29s IHRyaWVkX3RvX2luaXRpYWxpemVfb25jZTsKKyAgc3RhdGljIGJvb2wgZ2Njaml0X2luaXRpYWxp emVkOworCisgIGlmICghdHJpZWRfdG9faW5pdGlhbGl6ZV9vbmNlKQorICAgIHsKKyAgICAgIHRy aWVkX3RvX2luaXRpYWxpemVfb25jZSA9IHRydWU7CisgICAgICBMaXNwX09iamVjdCBzdGF0dXM7 CisgICAgICBnY2NqaXRfaW5pdGlhbGl6ZWQgPSBpbml0X2djY2ppdF9mdW5jdGlvbnMgKCk7Cisg ICAgICBzdGF0dXMgPSBnY2NqaXRfaW5pdGlhbGl6ZWQgPyBRdCA6IFFuaWw7CisgICAgICBWbGli cmFyeV9jYWNoZSA9IEZjb25zIChGY29ucyAoUWdjY2ppdCwgc3RhdHVzKSwgVmxpYnJhcnlfY2Fj aGUpOworICAgIH0KKworICBpZiAobWFuZGF0b3J5ICYmICFnY2NqaXRfaW5pdGlhbGl6ZWQpCisg ICAgeHNpZ25hbDEoUW5hdGl2ZV9jb21waWxlcl9lcnJvciwgYnVpbGRfc3RyaW5nKCJsaWJnY2Nq aXQgbm90IGZvdW5kIikpOworCisgIHJldHVybiBnY2NqaXRfaW5pdGlhbGl6ZWQ7CisjZWxzZQor ICByZXR1cm4gdHJ1ZTsKKyNlbmRpZgorfQorCisMCiAvKiBDIHN5bWJvbHMgZW1pdHRlZCBmb3Ig dGhlIGxvYWQgcmVsb2NhdGlvbiBtZWNoYW5pc20uICAqLwogI2RlZmluZSBDVVJSRU5UX1RIUkVB RF9SRUxPQ19TWU0gImN1cnJlbnRfdGhyZWFkX3JlbG9jIgogI2RlZmluZSBQVVJFX1BUUl9TWU0g InB1cmVfcHRyIgpAQCAtMzMyOCw2ICszNjcwLDggQEAgREVGVU4gKCJjb21wLS1pbml0LWN0eHQi LCBGY29tcF9faW5pdF9jdHh0LCBTY29tcF9faW5pdF9jdHh0LAogICAgICAgIGRvYzogLyogSW5p dGlhbGl6ZSB0aGUgbmF0aXZlIGNvbXBpbGVyIGNvbnRleHQuIFJldHVybiB0IG9uIHN1Y2Nlc3Mu ICAqLykKICAgICAgKHZvaWQpCiB7CisgIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSh0cnVlKTsK KwogICBpZiAoY29tcC5jdHh0KQogICAgIHsKICAgICAgIHhzaWduYWwxIChRbmF0aXZlX2ljZSwK QEAgLTM0NzQsNiArMzgxOCw4IEBAIERFRlVOICgiY29tcC0tcmVsZWFzZS1jdHh0IiwgRmNvbXBf X3JlbGVhc2VfY3R4dCwgU2NvbXBfX3JlbGVhc2VfY3R4dCwKICAgICAgICBkb2M6IC8qIFJlbGVh c2UgdGhlIG5hdGl2ZSBjb21waWxlciBjb250ZXh0LiAgKi8pCiAgICAgICh2b2lkKQogeworICBs b2FkX2djY2ppdF9pZl9uZWNlc3NhcnkodHJ1ZSk7CisKICAgaWYgKGNvbXAuY3R4dCkKICAgICBn Y2Nfaml0X2NvbnRleHRfcmVsZWFzZSAoY29tcC5jdHh0KTsKIApAQCAtMzQ5MCw2ICszODM2LDgg QEAgREVGVU4gKCJjb21wLS1jb21waWxlLWN0eHQtdG8tZmlsZSIsIEZjb21wX19jb21waWxlX2N0 eHRfdG9fZmlsZSwKICAgICAgICBkb2M6IC8qIENvbXBpbGUgYXMgbmF0aXZlIGNvZGUgdGhlIGN1 cnJlbnQgY29udGV4dCB0byBmaWxlLiAgKi8pCiAgICAgIChMaXNwX09iamVjdCBiYXNlX25hbWUp CiB7CisgIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSh0cnVlKTsKKwogICBDSEVDS19TVFJJTkcg KGJhc2VfbmFtZSk7CiAKICAgZ2NjX2ppdF9jb250ZXh0X3NldF9pbnRfb3B0aW9uIChjb21wLmN0 eHQsCkBAIC0zNjYwLDYgKzQwMDgsOSBAQCBtYXliZV9kZWZlcl9uYXRpdmVfY29tcGlsYXRpb24g KExpc3BfT2JqZWN0IGZ1bmN0aW9uX25hbWUsCiAgICAgICBmZmx1c2ggKGYpOwogICAgIH0KICNl bmRpZgorICBpZiAoIWxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeShmYWxzZSkpCisgICAgcmV0dXJu OworCiAgIGlmICghY29tcF9kZWZlcnJlZF9jb21waWxhdGlvbgogICAgICAgfHwgbm9uaW50ZXJh Y3RpdmUKICAgICAgIHx8ICFOSUxQIChWcHVyaWZ5X2ZsYWcpCkBAIC0zOTI4LDEwICs0Mjc5LDI2 IEBAIERFRlVOICgibmF0aXZlLWVsaXNwLWxvYWQiLCBGbmF0aXZlX2VsaXNwX2xvYWQsIFNuYXRp dmVfZWxpc3BfbG9hZCwgMSwgMiwgMCwKICAgcmV0dXJuIFF0OwogfQogCisjZW5kaWYgLyogSEFW RV9OQVRJVkVfQ09NUCAqLworCitERUZVTiAoIm5hdGl2ZS1jb21wLWF2YWlsYWJsZS1wIiwgRm5h dGl2ZV9jb21wX2F2YWlsYWJsZV9wLAorICAgICAgIFNuYXRpdmVfY29tcF9hdmFpbGFibGVfcCwg MCwgMCwgMCwKKyAgICAgICBkb2M6IC8qIFJldHVybnMgdCBpZiBuYXRpdmUgY29tcGlsYXRpb24g b2YgTGlzcCBmaWxlcyBpcyBhdmFpbGFibGUgaW4KK3RoaXMgaW5zdGFuY2Ugb2YgRW1hY3MuICov KQorICAodm9pZCkKK3sKKyNpZmRlZiBIQVZFX05BVElWRV9DT01QCisgIHJldHVybiBsb2FkX2dj Y2ppdF9pZl9uZWNlc3NhcnkoZmFsc2UpID8gUXQgOiBRbmlsOworI2Vsc2UKKyAgcmV0dXJuIFFu aWw7CisjZW5kaWYKK30KKwogDAogdm9pZAogc3ltc19vZl9jb21wICh2b2lkKQogeworI2lmZGVm IEhBVkVfTkFUSVZFX0NPTVAKICAgLyogQ29tcGlsZXIgY29udHJvbCBjdXN0b21pemVzLiAgKi8K ICAgREVGVkFSX0JPT0wgKCJjb21wLWRlZmVycmVkLWNvbXBpbGF0aW9uIiwgY29tcF9kZWZlcnJl ZF9jb21waWxhdGlvbiwKIAkgICAgICAgZG9jOiAvKiBJZiB0IGNvbXBpbGUgYXN5bmNyb25vdXNs eSBldmVyeSAuZWxjIGZpbGUgbG9hZGVkLiAgKi8pOwpAQCAtNDA3Myw2ICs0NDQwLDcgQEAgc3lt c19vZl9jb21wICh2b2lkKQogCSAgICAgICBkb2M6IC8qIEhhc2ggdGFibGUgc3ltYm9sLW5hbWUg LT4gZnVuY3Rpb24tdmFsdWUuICBGb3IKIAkJICAgICAgIGludGVybmFsIHVzZSBkdXJpbmcgICov KTsKICAgVmNvbXBfZGVmZXJyZWRfcGVuZGluZ19oID0gQ0FMTE4gKEZtYWtlX2hhc2hfdGFibGUs IFFDdGVzdCwgUWVxKTsKLX0KKyNlbmRpZgogCi0jZW5kaWYgLyogSEFWRV9OQVRJVkVfQ09NUCAq LworICBkZWZzdWJyICgmU25hdGl2ZV9jb21wX2F2YWlsYWJsZV9wKTsKK30KZGlmZiAtLWdpdCBh L3NyYy9jb21wLmggYi9zcmMvY29tcC5oCmluZGV4IGNiZGNhY2NkNWYuLmU2YWIzMmZmOGUgMTAw NjQ0Ci0tLSBhL3NyYy9jb21wLmgKKysrIGIvc3JjL2NvbXAuaApAQCAtODIsMTEgKzgyLDcgQEAg bWF5YmVfZGVmZXJfbmF0aXZlX2NvbXBpbGF0aW9uIChMaXNwX09iamVjdCBmdW5jdGlvbl9uYW1l LAogCQkJCUxpc3BfT2JqZWN0IGRlZmluaXRpb24pCiB7fQogCi1zdGF0aWMgaW5saW5lIExpc3Bf T2JqZWN0Ci1GbmF0aXZlX2VsaXNwX2xvYWQgKExpc3BfT2JqZWN0IGZpbGUsIExpc3BfT2JqZWN0 IGxhdGVfbG9hZCkKLXsKLSAgZWFzc3VtZSAoZmFsc2UpOwotfQorZXh0ZXJuIHZvaWQgc3ltc19v Zl9jb21wICh2b2lkKTsKIAogI2VuZGlmCiAKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy5jIGIvc3Jj L2VtYWNzLmMKaW5kZXggMmM5MDgyNTc0Mi4uZTc1Y2I1ODgzNCAxMDA2NDQKLS0tIGEvc3JjL2Vt YWNzLmMKKysrIGIvc3JjL2VtYWNzLmMKQEAgLTE2MDYsMTAgKzE2MDYsOCBAQCBtYWluIChpbnQg YXJnYywgY2hhciAqKmFyZ3YpCiAgIGluaXRfanNvbiAoKTsKICNlbmRpZgogCi0jaWZkZWYgSEFW RV9OQVRJVkVfQ09NUAogICBpZiAoIWluaXRpYWxpemVkKQogICAgIHN5bXNfb2ZfY29tcCAoKTsK LSNlbmRpZgogCiAgIG5vX2xvYWR1cAogICAgID0gYXJnbWF0Y2ggKGFyZ3YsIGFyZ2MsICItbmwi LCAiLS1uby1sb2FkdXAiLCA2LCBOVUxMLCAmc2tpcF9hcmdzKTsKZGlmZiAtLWdpdCBhL3NyYy93 MzIuYyBiL3NyYy93MzIuYwppbmRleCBhOGM3NjNmMjNlLi5jZWI4ZjdlZjY2IDEwMDY0NAotLS0g YS9zcmMvdzMyLmMKKysrIGIvc3JjL3czMi5jCkBAIC0xMDU4Niw2ICsxMDU4NiwxMCBAQCBnbG9i YWxzX29mX3czMiAodm9pZCkKICNlbmRpZgogCiAgIHczMl9jcnlwdG9faHByb3YgPSAoSENSWVBU UFJPVikwOworCisgIC8qIFdlIG5lZWQgdG8gZm9yZ2V0IGFib3V0IGxpYnJhcmllcyB0aGF0IHdl cmUgbG9hZGVkIGR1cmluZyB0aGUKKyAgICAgZHVtcGluZyBwcm9jZXNzIChlLmcuIGxpYmdjY2pp dCkgKi8KKyAgVmxpYnJhcnlfY2FjaGUgPSBRbmlsOwogfQogCiAvKiBGb3IgbWFrZS1zZXJpYWwt cHJvY2VzcyAgKi8KZGlmZiAtLWdpdCBhL3NyYy93MzJmbnMuYyBiL3NyYy93MzJmbnMuYwppbmRl eCBlNTk1YjAyODVhLi5lZWI3MzQ4OWRkIDEwMDY0NAotLS0gYS9zcmMvdzMyZm5zLmMKKysrIGIv c3JjL3czMmZucy5jCkBAIC0xMDQ2Miw2ICsxMDQ2Miw3IEBAIHN5bXNfb2ZfdzMyZm5zICh2b2lk KQogICBERUZTWU0gKFF6bGliLCAiemxpYiIpOwogICBERUZTWU0gKFFsY21zMiwgImxjbXMyIik7 CiAgIERFRlNZTSAoUWpzb24sICJqc29uIik7CisgIERFRlNZTSAoUWdjY2ppdCwgImdjY2ppdCIp OwogCiAgIEZwdXQgKFF1bmRlZmluZWRfY29sb3IsIFFlcnJvcl9jb25kaXRpb25zLAogCXB1cmVf bGlzdCAoUXVuZGVmaW5lZF9jb2xvciwgUWVycm9yKSk7Ci0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000e9dc2405a58c90b2 Content-Type: application/octet-stream; name="0008-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Disposition: attachment; filename="0008-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ka5qjdfo7 RnJvbSAyYmMwNTQzMTc3NTZmMmU4MWJlZTc2NmFkMzg4OGZiYWQ0Y2VjYzQ2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAxMyBNYXkgMjAyMCAxNjoy MjoxNyAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggOC84XSBXaW5kb3dzOiBVc2UgTlVNQkVSX09GX1BS T0NFU1NPUlMgZW52aXJvbm1lbnQgdmFyaWFibGUuCgoqIGxpc3AvZW1hY3MtbGlzcC9jb21wLmVs IChjb21wLWVmZmVjdGl2ZS1hc3luYy1tYXgtam9icyk6IFVzZQpOVU1CRVJfT0ZfUFJPQ0VTU09S UyBlbnZpcm9ubWVudCB2YXJpYWJsZSBpZiBzeXN0ZW0gaXMgV2luZG93cyBOVCwKIm5wcm9jIiBp ZiBpdCBpcyBpbiBQQVRIIG9yIGEgZGVmYXVsdCBvZiAxLgotLS0KIGxpc3AvZW1hY3MtbGlzcC9j b21wLmVsIHwgOCArKysrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMyBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCBiL2xpc3Av ZW1hY3MtbGlzcC9jb21wLmVsCmluZGV4IGQzMmY5M2ExZTEuLjI2YmI3OWZjZDEgMTAwNjQ0Ci0t LSBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCisrKyBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVs CkBAIC0yMjA4LDkgKzIyMDgsMTEgQEAgY29tcC1hc3luYy1ydW5uaW5ncwogICAgIChpZiAoemVy b3AgY29tcC1hc3luYy1qb2JzLW51bWJlcikKICAgICAgICAgKG9yIG51bS1jcHVzCiAgICAgICAg ICAgICAoc2V0ZiBudW0tY3B1cwotICAgICAgICAgICAgICAgICAgOzsgSGFsZiBvZiB0aGUgQ1BV cyBvciBhdCBsZWFzdCBvbmUuCi0gICAgICAgICAgICAgICAgICA7OyBGSVhNRSBwb3J0YWJsZT8K LSAgICAgICAgICAgICAgICAgIChtYXggMSAoLyAoc3RyaW5nLXRvLW51bWJlciAoc2hlbGwtY29t bWFuZC10by1zdHJpbmcgIm5wcm9jIikpCisgICAgICAgICAgICAgICAgICAobWF4IDEgKC8gKGNv bmQgKChlcSAnd2luZG93cy1udCBzeXN0ZW0tdHlwZSkKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKHN0cmluZy10by1udW1iZXIgKGdldGVudiAiTlVNQkVSX09GX1BST0NFU1NP UlMiKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKChleGVjdXRhYmxlLWZp bmQgIm5wcm9jIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmluZy10 by1udW1iZXIgKHNoZWxsLWNvbW1hbmQtdG8tc3RyaW5nICJucHJvYyIpKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAodCAxKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAyKSkpKQogICAgICAgY29tcC1hc3luYy1qb2JzLW51bWJlcikpKQogCi0tIAoyLjI1LjEud2lu ZG93cy4xCgo= --000000000000e9dc2405a58c90b2-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 15:36:44 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 19:36:44 +0000 Received: from localhost ([127.0.0.1]:59620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxBM-00084N-IQ for submit@debbugs.gnu.org; Wed, 13 May 2020 15:36:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxBJ-000845-6C for 41242@debbugs.gnu.org; Wed, 13 May 2020 15:36:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44328) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYxBD-0001wM-Rs; Wed, 13 May 2020 15:36:35 -0400 Received: from [176.228.60.248] (port=3125 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jYxBD-0001Mh-2B; Wed, 13 May 2020 15:36:35 -0400 Date: Wed, 13 May 2020 22:36:17 +0300 Message-Id: <83pnb7630u.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Wed, 13 May 2020 16:26:57 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (---) > From: Nicolas Bértolo > Date: Wed, 13 May 2020 16:26:57 -0300 > > * The loading process is very slow. This is especially annoying when coupled > with autoloading. For example, autoloading Helm may stall Emacs for 5 seconds > in my machine. Did you manage to understand why? How many bytes of *.eln files does Emacs load while autoloading Helm, for example? From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 15:40:22 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 19:40:22 +0000 Received: from localhost ([127.0.0.1]:59630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxEs-0008A5-7O for submit@debbugs.gnu.org; Wed, 13 May 2020 15:40:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxEq-00089o-KQ for 41242@debbugs.gnu.org; Wed, 13 May 2020 15:40:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44403) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYxEl-0002Ri-C0; Wed, 13 May 2020 15:40:15 -0400 Received: from [176.228.60.248] (port=3347 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jYxEk-0001e3-MO; Wed, 13 May 2020 15:40:15 -0400 Date: Wed, 13 May 2020 22:39:58 +0300 Message-Id: <83o8qr62up.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Wed, 13 May 2020 16:26:57 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (---) > From: Nicolas Bértolo > Date: Wed, 13 May 2020 16:26:57 -0300 > > * `package-delete` fails because it tries to delete the .eln file via > `delete-file`. This is impossible in Windows because it's generally impossible > to delete files that have an open HANDLE in the system. Is that the handle from LoadLibrary? If so, cannot we close the handle once the .eln file is loaded? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 15:56:51 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 19:56:51 +0000 Received: from localhost ([127.0.0.1]:59658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxUp-00008A-4x for submit@debbugs.gnu.org; Wed, 13 May 2020 15:56:51 -0400 Received: from mx.sdf.org ([205.166.94.20]:58776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxUn-000081-C7 for 41242@debbugs.gnu.org; Wed, 13 May 2020 15:56:50 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04DJukbb009199 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 13 May 2020 19:56:47 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04DJukFJ008523; Wed, 13 May 2020 19:56:46 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: Date: Wed, 13 May 2020 19:56:46 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 16:26:57 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > The attached patches contain changes to make the feature/native-comp bran= ch work > on Windows. > > There are a few remaining issues: > > * The loading process is very slow. This is especially annoying when coup= led > with autoloading. For example, autoloading Helm may stall Emacs for 5 s= econds > in my machine. > > I have thought a possible solution to this problem: load the byte-compi= led > file and put the native-compiled version in a list. Then load that list= one by > one on an idle-timer, that way the UI freezes should be minimized. This= could > reuse the "late loading" machinery implemented for deferred compilation. That's an option, but before implementing any machinery base on a timers we need to profile to understand where we are loosing the time. The timer is a mitigation but will still freeze the editor so it's a last resource. What is the state of your paperwork? I guess still ongoing am I correct? Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 16:02:19 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 20:02:19 +0000 Received: from localhost ([127.0.0.1]:59667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxa7-0000IJ-29 for submit@debbugs.gnu.org; Wed, 13 May 2020 16:02:19 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:43782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxa5-0000I7-Nt for 41242@debbugs.gnu.org; Wed, 13 May 2020 16:02:18 -0400 Received: by mail-oi1-f178.google.com with SMTP id i22so5944665oik.10 for <41242@debbugs.gnu.org>; Wed, 13 May 2020 13:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Zh3n5M8sbscu+0BCETWzKIW/Dc4I/m0PuXttr712oCk=; b=lM7u/RBbsm933sdju1M6CJTIFbOyrjbWOfgMAgi4eWGJXm6CRnxXVAokfo+ndAEw2q 90VN5eiaFpF/+ktMkL0KZFOVytcUtFTJWwnphtG+sLki6fNFBQgDxIKrGtIM1Z7CW2S/ Q0bhkWgWRqHAD3VV+QLrgXbvVceFP71GRk2JUtm9zUKIjisfqXuV2Io+OJrGQvesxAia jDLutKUfxVwUT73Jba1S3BRvcw6W+a1It5EDEl8Khg64bt/q8ruWbs6YAQKgsdkepu8r Aow88ji1HKmJsr5ge324ef/pRNCaB7ogx9pjkUQPqALn4ZdETSu31wgQNNcpdLyT5YCP 57cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zh3n5M8sbscu+0BCETWzKIW/Dc4I/m0PuXttr712oCk=; b=DErFRubp9B1u2sqyG/cXTY3NrUNN//iYTHDfcLS8rAUDlqZirixcPj6x/Erb7zD8nw 6IZPGhyCvKTtOdljq3cSZp+MfoKZpyFntFkxXmlFsH4szHSwYctyYZca3gXuXLWapn9O 1l1Qk1R2l7DILs1bvTC0iy4jnlugtrYWpL57rl2NDFn8qsDzbagt5wo0QXeeHl7UauU1 GEV12wN8O7xU8iPnpmKcFqnrTeQr4tBz+srNhEDai5r3avFl4om0b3LUPAHIbMJetyNq 7Zp4YrrGPkUi+mUNTnbcrPap2EoA1VTNXRkwvpYIZ4uaOaITf4KmkjkVJDRBsldF1PPs JILA== X-Gm-Message-State: AGi0PubcdicG50bGE8uouxb99uaAIcjeGgBi37057EX5iEcImJWXLPIR Vap7HVXS+Km+H8xsMdCWrTfqsKB18CjQwUSGC6M= X-Google-Smtp-Source: APiQypKNeFqgipf8TV9IwV1daHJOAGMTvZT9DdcbkKbzwotrRsqMuhuIN0Byg8Zd9JewRPmmrOZzi2cXu8d+a+MwXjM= X-Received: by 2002:a05:6808:98f:: with SMTP id a15mr28570416oic.65.1589400131847; Wed, 13 May 2020 13:02:11 -0700 (PDT) MIME-Version: 1.0 References: <83o8qr62up.fsf@gnu.org> In-Reply-To: <83o8qr62up.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 13 May 2020 17:01:59 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii , Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > Did you manage to understand why? How many bytes of *.eln files does > Emacs load while autoloading Helm, for example? I don't know how to measure that, sorry. AFAIK Emacs just maps many subr to= the correct function pointers and the OS takes care of loading the appropriate = code on page faults. My guess is that autoloading triggers a long series of eln loading operatio= ns, that, as a group, are very expensive. Do you know what profiler I could use to check what Emacs is doing? > Is that the handle from LoadLibrary? If so, cannot we close the > handle once the .eln file is loaded? Exactly. No, calling FreeLibrary would unload the file from the address spa= ce. El mi=C3=A9., 13 may. 2020 a las 16:40, Eli Zaretskii () escr= ibi=C3=B3: > > > From: Nicolas B=C3=A9rtolo > > Date: Wed, 13 May 2020 16:26:57 -0300 > > > > * `package-delete` fails because it tries to delete the .eln file via > > `delete-file`. This is impossible in Windows because it's generally i= mpossible > > to delete files that have an open HANDLE in the system. > > Is that the handle from LoadLibrary? If so, cannot we close the > handle once the .eln file is loaded? > > Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 16:04:11 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 20:04:11 +0000 Received: from localhost ([127.0.0.1]:59671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxbv-0000L8-D1 for submit@debbugs.gnu.org; Wed, 13 May 2020 16:04:11 -0400 Received: from mail-oi1-f177.google.com ([209.85.167.177]:33646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxbt-0000Kv-PX for 41242@debbugs.gnu.org; Wed, 13 May 2020 16:04:10 -0400 Received: by mail-oi1-f177.google.com with SMTP id o24so22562647oic.0 for <41242@debbugs.gnu.org>; Wed, 13 May 2020 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a7NaiPCEdujgQKfLNlpktxI4MI2cQb8WbxVile0MpXY=; b=o92c3Do/uwp+nNeFypeAkB4bnrvtvWkTKhpOzJSKU7VEzpdR8zh7gf2759LEN5roMY ypvOZ1GJcyikUDwafBxHQFVAQ3Ctg5UCjFXpTCJtMTSxOsvVKN0DZzTTL4GEmVDF0O2I 2VU6oymPwrwzVjWtPVXhFvQBnLNz9MP0oRlRq33tXOnQlBdbiSSfmh4P277JFJ290F43 tjof9A3GIB/V2pLMMTrfbPpMe5OfYo3pFwn1zazCYrwSIsi3FYcJWN9vYv9uc9xgQTId iSSdLHxzY9LxXirOIBXSMlPKRyFlHdEW8DxmpzZ+kM7qaaMUmMNhzQWiFTQfbDhJRHnS pWLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a7NaiPCEdujgQKfLNlpktxI4MI2cQb8WbxVile0MpXY=; b=JGkU5V26dV/bLE02OLNyAQpM5uqaaxs/EDTFNEqAx4OlMajDxrCUF2lCGxeJDor0PG QnwnGaUcUfjyPeRBaENtOUxiXhpKOWXfQ9mD52k3sC61V5072662LxhmSlHP0SrLgqnb ooP7Vs96sEPtkVgyL6TyEsfxOVA8jfdegWXIiTDr60DTnkDNKoJXmRJoJ6UYAQEM70mC Khx5+wof809wMGpl3ZdV9I5s4fVOvfG1Lc5ZWpj0ri3WF7W9UuwBgDfZFxaRVhTl9DMH Ka2eAROiFMT9lNIlTjHGm/G8vvFJJiXs4tKUMBkIODABffxejFy0PRLXSgeHFr8igv1o aXaA== X-Gm-Message-State: AGi0PuZKgJigEBWaHn4SfCwU0TpZHWbW7fyrMvCysuQms3noCijyudpb absEntt4qprPZ7QxOk1tx05wCurt2CPilQddi2w= X-Google-Smtp-Source: APiQypKicW0uiaH7xN5SCrxZbTjPD6jo/C9t5t9gk7uUqVevcV34roiuQpzwoxeRwf+XOruwShkuE5fn1+BZyDeZRlM= X-Received: by 2002:a05:6808:98f:: with SMTP id a15mr28577506oic.65.1589400244349; Wed, 13 May 2020 13:04:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 13 May 2020 17:03:52 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > What is the state of your paperwork? I guess still ongoing am I > correct? I have already sent the signed form. I haven't got a response yet. El mi=C3=A9., 13 may. 2020 a las 16:56, Andrea Corallo () esc= ribi=C3=B3: > > Nicolas B=C3=A9rtolo writes: > > > The attached patches contain changes to make the feature/native-comp br= anch work > > on Windows. > > > > There are a few remaining issues: > > > > * The loading process is very slow. This is especially annoying when co= upled > > with autoloading. For example, autoloading Helm may stall Emacs for 5= seconds > > in my machine. > > > > I have thought a possible solution to this problem: load the byte-com= piled > > file and put the native-compiled version in a list. Then load that li= st one by > > one on an idle-timer, that way the UI freezes should be minimized. Th= is could > > reuse the "late loading" machinery implemented for deferred compilati= on. > > That's an option, but before implementing any machinery base on a timers > we need to profile to understand where we are loosing the time. > > The timer is a mitigation but will still freeze the editor so it's a > last resource. > > What is the state of your paperwork? I guess still ongoing am I > correct? > > Thanks > > Andrea > > -- > akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 16:08:46 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 20:08:46 +0000 Received: from localhost ([127.0.0.1]:59675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxgL-0000RV-Up for submit@debbugs.gnu.org; Wed, 13 May 2020 16:08:46 -0400 Received: from mx.sdf.org ([205.166.94.20]:57014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxgK-0000RO-HM for 41242@debbugs.gnu.org; Wed, 13 May 2020 16:08:45 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04DK8hMM015652 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 13 May 2020 20:08:43 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04DK8hw7012267; Wed, 13 May 2020 20:08:43 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83o8qr62up.fsf@gnu.org> Date: Wed, 13 May 2020 20:08:43 +0000 In-Reply-To: <83o8qr62up.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 May 2020 22:39:58 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: >> From: Nicolas B=C3=A9rtolo >> Date: Wed, 13 May 2020 16:26:57 -0300 >>=20 >> * `package-delete` fails because it tries to delete the .eln file via >> `delete-file`. This is impossible in Windows because it's generally im= possible >> to delete files that have an open HANDLE in the system. > > Is that the handle from LoadLibrary? If so, cannot we close the > handle once the .eln file is loaded? AFAIU we cannot close the handle till we have code around (compiled Lisp function) coming from the eln. Andrea PS BTW I see now we never close the handle but this is a bug, I'll fix now. --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 16:27:53 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 20:27:53 +0000 Received: from localhost ([127.0.0.1]:59681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxyr-0000tH-KZ for submit@debbugs.gnu.org; Wed, 13 May 2020 16:27:53 -0400 Received: from mx.sdf.org ([205.166.94.20]:53646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYxyq-0000t9-FU for 41242@debbugs.gnu.org; Wed, 13 May 2020 16:27:53 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04DKRoB5013249 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 13 May 2020 20:27:50 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04DKRo5A025576; Wed, 13 May 2020 20:27:50 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83o8qr62up.fsf@gnu.org> Date: Wed, 13 May 2020 20:27:50 +0000 In-Reply-To: (Andrea Corallo's message of "Wed, 13 May 2020 20:08:43 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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 (-) Andrea Corallo writes: > PS BTW I see now we never close the handle but this is a bug, I'll fix now. Ah no we do it already. Missed that sorry I'm fused. -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 13 18:25:32 2020 Received: (at 41242) by debbugs.gnu.org; 13 May 2020 22:25:32 +0000 Received: from localhost ([127.0.0.1]:59769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYzoh-0003lk-Q8 for submit@debbugs.gnu.org; Wed, 13 May 2020 18:25:31 -0400 Received: from mx.sdf.org ([205.166.94.20]:60810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jYzof-0003la-9I for 41242@debbugs.gnu.org; Wed, 13 May 2020 18:25:29 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04DMPSra019951 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 13 May 2020 22:25:28 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04DMPRTJ020926; Wed, 13 May 2020 22:25:27 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83o8qr62up.fsf@gnu.org> Date: Wed, 13 May 2020 22:25:27 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 17:01:59 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Did you manage to understand why? How many bytes of *.eln files does >> Emacs load while autoloading Helm, for example? > > I don't know how to measure that, sorry. AFAIK Emacs just maps many subr = to the > correct function pointers and the OS takes care of loading the appropriat= e code > on page faults. Loading elns quite stress also the reader that is still used to deserialize all objects except functions. The fact that the load is that slower on Windows seems to indicate that the equivalent dlopen dlsym are less performant than the other systems we have tried (the reader should be quite the same). That said there must be a way to profile on Windows so we get a picture of what is going on. --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 06:18:29 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 10:18:29 +0000 Received: from localhost ([127.0.0.1]:60337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZAwf-0001P9-92 for submit@debbugs.gnu.org; Thu, 14 May 2020 06:18:29 -0400 Received: from mx.sdf.org ([205.166.94.20]:60888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZAwd-0001P1-If for 41242@debbugs.gnu.org; Thu, 14 May 2020 06:18:28 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EAIQvF020271 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 10:18:26 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EAIQ5M021178; Thu, 14 May 2020 10:18:26 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: Date: Thu, 14 May 2020 10:18:26 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 16:26:57 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > * `package-delete` fails because it tries to delete the .eln file via > `delete-file`. This is impossible in Windows because it's generally imp= ossible > to delete files that have an open HANDLE in the system. > > Three solutions have crossed my mind: > > - Edit `package-delete` to put the eln on a list of files that should be > deleted when Emacs is closed. > > - Implement an unloading mechanism for native-compiled files. > > - Copy eln files to temporary files and load those temporary files inst= ead. > This means that deleting the original eln file is possible. > > I'd prefer the second option, but I have a semi-working patch for the t= hird > option. I don't think the second is an option. The unload machanism is already in place but is GC driven, I don't see how else it could work. --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 06:45:31 2020 Received: (at submit) by debbugs.gnu.org; 14 May 2020 10:45:31 +0000 Received: from localhost ([127.0.0.1]:60424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZBMp-0002Qj-9P for submit@debbugs.gnu.org; Thu, 14 May 2020 06:45:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:55534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZBMk-0002QW-Vm for submit@debbugs.gnu.org; Thu, 14 May 2020 06:45:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZBMk-0008CT-Ma for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 06:45:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58190) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZBMk-000610-1S; Thu, 14 May 2020 06:45:26 -0400 Received: from [176.12.137.152] (port=33656 helo=[10.212.174.103]) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1jZBMj-0004gI-B8; Thu, 14 May 2020 06:45:25 -0400 Date: Thu, 14 May 2020 13:45:20 +0300 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: bug#41242: Port feature/native-comp to Windows To: bug-gnu-emacs@gnu.org, Andrea Corallo , =?ISO-8859-1?Q?Nicolas_B=E9rtolo?= From: Eli Zaretskii Message-ID: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: 41242@debbugs.gnu.org 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 (---) On May 14, 2020 1:18:26 PM GMT+03:00, Andrea Corallo wrote= : > Nicolas B=C3=A9rtolo writes: >=20 > > * `package-delete` fails because it tries to delete the =2Eeln file > via > > `delete-file`=2E This is impossible in Windows because it's > generally impossible > > to delete files that have an open HANDLE in the system=2E > > > > Three solutions have crossed my mind: > > > > - Edit `package-delete` to put the eln on a list of files that > should be > > deleted when Emacs is closed=2E > > > > - Implement an unloading mechanism for native-compiled files=2E > > > > - Copy eln files to temporary files and load those temporary files > instead=2E > > This means that deleting the original eln file is possible=2E > > > > I'd prefer the second option, but I have a semi-working patch for > the third > > option=2E >=20 > I don't think the second is an option=2E The unload machanism is > already > in place but is GC driven, I don't see how else it could work=2E Windows doesn't let you delete a shared library that's loaded by a process= , but it does let you rename it=2E So I think the solution would be to ren= ame the =2Eeln file to something like =2Eeln=2Eold, and then let the GC dri= ven unload machinery to delete that old file=2E Btw, what happens if more than one Emacs session have the same =2Eeln file= loaded, and one of them wants to recompile it? From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 07:17:18 2020 Received: (at submit) by debbugs.gnu.org; 14 May 2020 11:17:18 +0000 Received: from localhost ([127.0.0.1]:60477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZBra-0003Kg-FS for submit@debbugs.gnu.org; Thu, 14 May 2020 07:17:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:57486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZBrY-0003KX-RG for submit@debbugs.gnu.org; Thu, 14 May 2020 07:17:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZBrY-0004pB-L1 for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 07:17:16 -0400 Received: from mx.sdf.org ([205.166.94.20]:53444) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZBrX-0003q4-KK; Thu, 14 May 2020 07:17:16 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EBHBr4015738 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 11:17:11 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EBHBZP015990; Thu, 14 May 2020 11:17:11 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: Date: Thu, 14 May 2020 11:17:11 +0000 In-Reply-To: (Eli Zaretskii's message of "Thu, 14 May 2020 13:45:20 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/14 07:17:14 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , bug-gnu-emacs@gnu.org, 41242@debbugs.gnu.org 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: -2.3 (--) Eli Zaretskii writes: >> I don't think the second is an option. The unload machanism is >> already >> in place but is GC driven, I don't see how else it could work. > > Windows doesn't let you delete a shared library that's loaded by a > process, but it does let you rename it. So I think the solution would > be to rename the .eln file to something like .eln.old, and then let > the GC driven unload machinery to delete that old file. Do we have guarantees that each object is collected before Emacs is eventually closed? I thought is not the case. > Btw, what happens if more than one Emacs session have the same .eln file loaded, and one of them wants to recompile it? Now to avoid this problem we always delete the file before recompiling. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 09:43:00 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 13:43:00 +0000 Received: from localhost ([127.0.0.1]:60656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZE8a-0003XX-15 for submit@debbugs.gnu.org; Thu, 14 May 2020 09:43:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZE8Y-0003XJ-Ml for 41242@debbugs.gnu.org; Thu, 14 May 2020 09:42:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32899) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZE8T-00051h-Ar; Thu, 14 May 2020 09:42:53 -0400 Received: from [176.228.60.248] (port=1686 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZE8S-00057K-Qo; Thu, 14 May 2020 09:42:53 -0400 Date: Thu, 14 May 2020 16:42:36 +0300 Message-Id: <83lflu63ar.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Wed, 13 May 2020 17:01:59 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83o8qr62up.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Wed, 13 May 2020 17:01:59 -0300 > Cc: 41242@debbugs.gnu.org > > > Did you manage to understand why? How many bytes of *.eln files does > > Emacs load while autoloading Helm, for example? > > I don't know how to measure that, sorry. AFAIK Emacs just maps many subr to the > correct function pointers and the OS takes care of loading the appropriate code > on page faults. > > My guess is that autoloading triggers a long series of eln loading operations, > that, as a group, are very expensive. > > Do you know what profiler I could use to check what Emacs is doing? I'd begin with Emacs's built-in "M-x profiler-start". After invoking that, start the Helm loading command, and when it ends, invoke profiler-report. Post the resulting profile fully expanded, and maybe that will give some clues about what to examine next. It will also be useful to have a comparable measurement from GNU/Linux, so that we could compare the profiles and the elapsed times. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 10:32:52 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 14:32:52 +0000 Received: from localhost ([127.0.0.1]:34364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZEup-0005a7-JE for submit@debbugs.gnu.org; Thu, 14 May 2020 10:32:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZEuo-0005Zs-I9 for 41242@debbugs.gnu.org; Thu, 14 May 2020 10:32:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34112) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZEui-0000bD-9a; Thu, 14 May 2020 10:32:44 -0400 Received: from [176.228.60.248] (port=4735 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZEuh-0005a8-At; Thu, 14 May 2020 10:32:43 -0400 Date: Thu, 14 May 2020 17:32:28 +0300 Message-Id: <834ksi60zn.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Thu, 14 May 2020 11:17:11 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: bug-gnu-emacs@gnu.org, > Nicolas Bértolo > , > 41242@debbugs.gnu.org > Date: Thu, 14 May 2020 11:17:11 +0000 > > > Windows doesn't let you delete a shared library that's loaded by a > > process, but it does let you rename it. So I think the solution would > > be to rename the .eln file to something like .eln.old, and then let > > the GC driven unload machinery to delete that old file. > > Do we have guarantees that each object is collected before Emacs is > eventually closed? I thought is not the case. I don't know enough about the "GC driven unload" you mentioned, but if that is not bulletproof enough, we could add a kill-emacs hook to take care of this. And if push comes to shove, we could use a Windows API that causes a file to be deleted when the last handle on it is closed, but that would add complexity, so I think we should try easier ways first. > > Btw, what happens if more than one Emacs session have the same .eln file loaded, and one of them wants to recompile it? > > Now to avoid this problem we always delete the file before recompiling. But that's unportable, and won't work on Windows, for the same reasons as the issue we are discussing here. Or am I missing something? From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 11:03:13 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 15:03:13 +0000 Received: from localhost ([127.0.0.1]:34434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZFOD-0002H4-J6 for submit@debbugs.gnu.org; Thu, 14 May 2020 11:03:13 -0400 Received: from mx.sdf.org ([205.166.94.20]:65119) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZFO9-0002Gt-IC for 41242@debbugs.gnu.org; Thu, 14 May 2020 11:03:11 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EF38J6010136 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 15:03:08 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EF38Bp032306; Thu, 14 May 2020 15:03:08 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 15:03:08 +0000 In-Reply-To: <834ksi60zn.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 May 2020 17:32:28 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> From: Andrea Corallo >> Cc: bug-gnu-emacs@gnu.org, >> Nicolas B=C3=A9rtolo >> , >> 41242@debbugs.gnu.org >> Date: Thu, 14 May 2020 11:17:11 +0000 >> >> > Windows doesn't let you delete a shared library that's loaded by a >> > process, but it does let you rename it. So I think the solution would >> > be to rename the .eln file to something like .eln.old, and then let >> > the GC driven unload machinery to delete that old file. >> >> Do we have guarantees that each object is collected before Emacs is >> eventually closed? I thought is not the case. > > I don't know enough about the "GC driven unload" you mentioned, but if > that is not bulletproof enough, we could add a kill-emacs hook to take > care of this. And if push comes to shove, we could use a Windows API > that causes a file to be deleted when the last handle on it is closed, > but that would add complexity, so I think we should try easier ways > first. Now simply when the compilation unit object is collected, the handle is closed. The compilation unit is collected when is not reachable by any of the functions defined into. Loading a new compilation unit B that redefines the same functions defined by A does not guarantees much, some of the old definitions of A could be still in use somewhere, in that case A will not be collected. So yeah I think we need a specific mechanism (kill-emacs hook as you suggest) to do the cleanup when Emacs goes down. >> > Btw, what happens if more than one Emacs session have the same .eln fi= le loaded, and one of them wants to recompile it? >> >> Now to avoid this problem we always delete the file before recompiling. > > But that's unportable, and won't work on Windows, for the same reasons > as the issue we are discussing here. Or am I missing something? No you are right, I don't use Windows since forever, I discovered from this thread is not portable. I guess we'll need to rename also here. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 12:24:22 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 16:24:23 +0000 Received: from localhost ([127.0.0.1]:34563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZGek-0000OL-Kf for submit@debbugs.gnu.org; Thu, 14 May 2020 12:24:22 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:33910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZGei-0000O7-W8 for 41242@debbugs.gnu.org; Thu, 14 May 2020 12:24:21 -0400 Received: by mail-ot1-f54.google.com with SMTP id 72so2851025otu.1 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 09:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V76+5tk+mubLdVX27TFzEqElmhkGn9GxiXXp/FZwZg8=; b=hVHu+OV8QbsfacrgWV/lyWhT2mmP4+Zv8y7r4wYcMuhMkzP7+OfvqKZQVWVACZt+RS NKntzukT98+Vg0ki3xjF5XNAzqixtfS1I6ZFR7Y/2arKJsO44cuWC+LhdQz3qWZ2a7tN pBTrKemCqcbg7sSfNKTLF23Ede4peNgDzRFNX9vfnCc3Z9snE0G9NYkVsx9GyXm1YjZZ WZDwAbUDiTd5+13JNNQlatVIS+JiOxivjO4UK/LTD9SS5sxQ2vTcUGFLm4QC2v5NZyAP dVoShmvWeb0v5OXzZg8ueyw4IjcvZUpK1Yyn84ALWykx9RLPYZDVapyxN2D2Q673vDi+ kfoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V76+5tk+mubLdVX27TFzEqElmhkGn9GxiXXp/FZwZg8=; b=tFqi2+d9wLLkM3E6i9ALeAma7JpOzHB+Ty6TDvBRmWoDUGe/NWbJkWpeTxWNLoYhid OJq7KwnXVP/QVjnteTTK6WHNyMV8AofDN87ElQWVsxK5EBfnBE+fAuwbyBP74IP4Rif3 TTvo/jcfOfnEumGSkSa409HKtZB77OyLDuJKrQtJ4GX+eaZuM6w/EPFf7VFokZLZaGqx IdaauNT+9mNChRenkN+ZYfEBLUUwiHdh+Vd/pwAGDs091+Ilw+Nuhst4vOzMg3a4rDhN 0XvkOoq0zKqMqTLvka2DCSXNEnOIm95zr/2cZd4/Uy8s4yzvvgMK45y5Rs9StcLgEfHh 1GmQ== X-Gm-Message-State: AOAM5326vKa6pC1uW452FFH0UFomUO3sOTybG67qQGFsdLFyJaOhgsOd cY7F0diwwvyIeydFEE6X6WPOptuVRIIYAuAHIBU= X-Google-Smtp-Source: ABdhPJy7xzQhdwS63xGihMiEcVrShT95OmTOI7L4N7R7t4ZPcP6KsMa6ZpsPThzNtWiNqw42Zd71cdz33AKTxS0Bk2g= X-Received: by 2002:a9d:3988:: with SMTP id y8mr3961149otb.352.1589473454521; Thu, 14 May 2020 09:24:14 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: <834ksi60zn.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 13:24:02 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) > And if push comes to shove, we could use a Windows API > that causes a file to be deleted when the last handle on it is closed, > but that would add complexity, so I think we should try easier ways > first. If you are talking about FILE_FLAG_DELETE_ON_CLOSE: I have tried that in the patch I have for the third suggestion. When Emacs closes normally the temporary files are not deleted. I don't know why that is. It is as if the LoadLibrary function disabled the delete on close flag. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 12:51:08 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 16:51:08 +0000 Received: from localhost ([127.0.0.1]:34612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZH4d-0001Ao-LE for submit@debbugs.gnu.org; Thu, 14 May 2020 12:51:07 -0400 Received: from mail-ot1-f52.google.com ([209.85.210.52]:45149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZH4c-0001AK-7B for 41242@debbugs.gnu.org; Thu, 14 May 2020 12:51:06 -0400 Received: by mail-ot1-f52.google.com with SMTP id c3so2854834otr.12 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eSXZzT+RMBGmIjFmbUUnypfhrzGALT1zdgY45AFx1kM=; b=tbdU8OrW/rPP3CO5lfQpbl/MNyDjqQf8V0MNnN2E7TIw6vcmCzuP01dVaI/1oJA6dh RMGBYPJ3VXewrmgxHV0yn9LuRqTHmIOospMsrZ5+5VqIkDK25yopWli6Jq8oKDvkV8Fq +C8b9oJlQ6QJJ9JggMVkA3CpodCn6i0BdpDTtv8nF+08qY+vYCQf1qRZfTn/v2iSxlUF X+D7/06SkP3ayT5RsggrFTEkSXqF7bZtlvcu0Tf/aqexjvpNwn0VMH3bP0j8nH6bNUYD vhV6U2Usv01nF0pjK9D9P31A1e2cpuPQkukQNS5eviFbkobleEBLQFMJHjwxbAVy88v+ QSpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eSXZzT+RMBGmIjFmbUUnypfhrzGALT1zdgY45AFx1kM=; b=bbjI8TtoDeEd3EXk5IT2H8tCZ4g7RFKvJlQ6655SYVfWyw4MZ6LvVl/T7zvHeDQPWg 0cdnPAGVUslh0nX/drxhsdS0LGtkkM/2gdm5Nf8XnxAT98z9a8xTWgP6DnonkGMDkLln hHoave3YCAuLggGatbcZQ/SWb5o9mcWtFu3GK/6tAP/H6gTMWJFz7SAlSA6Z+J7q+TjA ilLo7MRyWiRIauBnjjKvLMZwUUaFmWy/MAjHKL0O9GbdfcPXxah9IAvnI1j23sbzbqCM h/NSzENdpa6cVeMVek4MvCkbH3+5P5SoosDrXC0vsI8li78Z9C0CMD5c1OJo9HP07pk+ BNgg== X-Gm-Message-State: AOAM531iO5q1BzFC+AbqPRvjrqFaGF6lVEQYWcBUBXIcVWBxXPqRB0Sa jXGlI6LIg2Yu7Q1Vc377tTDf5sn6KwQeN7oCVHM= X-Google-Smtp-Source: ABdhPJyTd1xdDUCoFESYxrN0RW2RwFFMrangC6wWB0AiLN8IK1jVBDrfA4no7ztn/VgpfD1ocMLZrKv9jrh6RNAHd5w= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr4238786oti.202.1589475060439; Thu, 14 May 2020 09:51:00 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 13:50:48 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > Loading a new compilation unit B that redefines the same functions > defined by A does not guarantees much, some of the old definitions of A > could be still in use somewhere, in that case A will not be collected. > So yeah I think we need a specific mechanism (kill-emacs hook as you > suggest) to do the cleanup when Emacs goes down. I was thinking about something like this: 1) Call `native-comp-unload`. 2) This should inspect the eln file and put all the subrs defined in it on = a list. This should also copy the original bytecode from the eln file and sto= re it somewhere. 3) Then `garbage-collect` is called. This should find all references to the subrs in the list and swap them atomically for references to functions from the bytecode. 4) After the previous step the GC should be able to collect the DLL handle knowing that no references to it remain. What do you think? > No you are right, I don't use Windows since forever, I discovered from > this thread is not portable. I guess we'll need to rename also here. But someone needs to delete the old eln file. Let's say that we use GetModuleFileNameA() to know if another Emacs instance has decided to renam= e the eln file and then we delete it on close if its suffix is ".eln.old". This algorithm has a big race condition though. If Emacs1 renames the file = after Emacs2 has checked that it has not been renamed, then the file won't be del= eted. If we put the "old eln" in the $TEMP folder this may not be a big issue tho= ugh. Nicolas. El jue., 14 may. 2020 a las 12:03, Andrea Corallo () escribi= =C3=B3: > > Eli Zaretskii writes: > > >> From: Andrea Corallo > >> Cc: bug-gnu-emacs@gnu.org, > >> Nicolas B=C3=A9rtolo > >> , > >> 41242@debbugs.gnu.org > >> Date: Thu, 14 May 2020 11:17:11 +0000 > >> > >> > Windows doesn't let you delete a shared library that's loaded by a > >> > process, but it does let you rename it. So I think the solution wou= ld > >> > be to rename the .eln file to something like .eln.old, and then let > >> > the GC driven unload machinery to delete that old file. > >> > >> Do we have guarantees that each object is collected before Emacs is > >> eventually closed? I thought is not the case. > > > > I don't know enough about the "GC driven unload" you mentioned, but if > > that is not bulletproof enough, we could add a kill-emacs hook to take > > care of this. And if push comes to shove, we could use a Windows API > > that causes a file to be deleted when the last handle on it is closed, > > but that would add complexity, so I think we should try easier ways > > first. > > Now simply when the compilation unit object is collected, the handle is > closed. The compilation unit is collected when is not reachable by any > of the functions defined into. > > Loading a new compilation unit B that redefines the same functions > defined by A does not guarantees much, some of the old definitions of A > could be still in use somewhere, in that case A will not be collected. > > So yeah I think we need a specific mechanism (kill-emacs hook as you > suggest) to do the cleanup when Emacs goes down. > > >> > Btw, what happens if more than one Emacs session have the same .eln = file loaded, and one of them wants to recompile it? > >> > >> Now to avoid this problem we always delete the file before recompiling= . > > > > But that's unportable, and won't work on Windows, for the same reasons > > as the issue we are discussing here. Or am I missing something? > > No you are right, I don't use Windows since forever, I discovered from > this thread is not portable. I guess we'll need to rename also here. > > Andrea > > -- > akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:14:31 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:14:31 +0000 Received: from localhost ([127.0.0.1]:34642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHRH-0001pG-II for submit@debbugs.gnu.org; Thu, 14 May 2020 13:14:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHRG-0001oz-6K for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:14:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38034) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZHRA-0002Sa-Vt; Thu, 14 May 2020 13:14:24 -0400 Received: from [176.228.60.248] (port=2654 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZHR5-0005D2-W0; Thu, 14 May 2020 13:14:24 -0400 Date: Thu, 14 May 2020 20:14:04 +0300 Message-Id: <831rnm5tib.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Thu, 14 May 2020 15:03:08 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org > Date: Thu, 14 May 2020 15:03:08 +0000 > > Now simply when the compilation unit object is collected, the handle is > closed. The compilation unit is collected when is not reachable by any > of the functions defined into. > > Loading a new compilation unit B that redefines the same functions > defined by A does not guarantees much, some of the old definitions of A > could be still in use somewhere, in that case A will not be collected. > > So yeah I think we need a specific mechanism (kill-emacs hook as you > suggest) to do the cleanup when Emacs goes down. Some list of files to remove and a function to remove them at exit should be sufficient. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:21:23 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:21:23 +0000 Received: from localhost ([127.0.0.1]:34678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHXv-00023J-3s for submit@debbugs.gnu.org; Thu, 14 May 2020 13:21:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHXt-000234-Js for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:21:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38273) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZHXo-0003tZ-5R; Thu, 14 May 2020 13:21:16 -0400 Received: from [176.228.60.248] (port=3072 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZHXn-0005nR-Dx; Thu, 14 May 2020 13:21:15 -0400 Date: Thu, 14 May 2020 20:21:00 +0300 Message-Id: <83zhaa4emb.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 13:24:02 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 13:24:02 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > And if push comes to shove, we could use a Windows API > > that causes a file to be deleted when the last handle on it is closed, > > but that would add complexity, so I think we should try easier ways > > first. > > If you are talking about FILE_FLAG_DELETE_ON_CLOSE: > I have tried that in the patch I have for the third suggestion. > When Emacs closes normally the temporary files are not deleted. > I don't know why that is. It is as if the LoadLibrary function disabled > the delete on close flag. Like I said: let's try more traditional ways first ;-) From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:29:02 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:29:02 +0000 Received: from localhost ([127.0.0.1]:34695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHfJ-0002I3-Gv for submit@debbugs.gnu.org; Thu, 14 May 2020 13:29:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHfH-0002Hk-Tx for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:29:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38497) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZHfB-0006Og-9m; Thu, 14 May 2020 13:28:53 -0400 Received: from [176.228.60.248] (port=3540 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZHfA-0001NF-5I; Thu, 14 May 2020 13:28:52 -0400 Date: Thu, 14 May 2020 20:28:36 +0300 Message-Id: <83wo5e4e9n.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 13:50:48 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 13:50:48 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > 1) Call `native-comp-unload`. > > 2) This should inspect the eln file and put all the subrs defined in it on a > list. This should also copy the original bytecode from the eln file and store it > somewhere. > > 3) Then `garbage-collect` is called. This should find all references to the > subrs in the list and swap them atomically for references to functions > from the bytecode. > > 4) After the previous step the GC should be able to collect the DLL handle > knowing that no references to it remain. > > What do you think? Do we really need this complexity? > > No you are right, I don't use Windows since forever, I discovered from > > this thread is not portable. I guess we'll need to rename also here. > > But someone needs to delete the old eln file. Let's say that we use > GetModuleFileNameA() to know if another Emacs instance has decided to rename the > eln file and then we delete it on close if its suffix is ".eln.old". > > This algorithm has a big race condition though. If Emacs1 renames the file after > Emacs2 has checked that it has not been renamed, then the file won't be deleted. Why do you need to check if it's renamed? Just rename always. > If we put the "old eln" in the $TEMP folder this may not be a big issue though. It is not good to move to $TEMP because that one could be on a different volume, and Windows won't let you do that with a DLL that is loaded into a process. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:34:40 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:34:40 +0000 Received: from localhost ([127.0.0.1]:34708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHkl-0004ad-SS for submit@debbugs.gnu.org; Thu, 14 May 2020 13:34:40 -0400 Received: from mx.sdf.org ([205.166.94.20]:54844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHkj-0004aU-Ht for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:34:38 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EHYaX3011542 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 17:34:36 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EHYaXs011032; Thu, 14 May 2020 17:34:36 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 17:34:36 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 13:50:48 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Loading a new compilation unit B that redefines the same functions >> defined by A does not guarantees much, some of the old definitions of A >> could be still in use somewhere, in that case A will not be collected. > >> So yeah I think we need a specific mechanism (kill-emacs hook as you >> suggest) to do the cleanup when Emacs goes down. > > I was thinking about something like this: > > 1) Call `native-comp-unload`. > > 2) This should inspect the eln file and put all the subrs defined in it o= n a > list. This should also copy the original bytecode from the eln file and s= tore it > somewhere. > > 3) Then `garbage-collect` is called. This should find all references to t= he > subrs in the list and swap them atomically for references to functions > from the bytecode. > > 4) After the previous step the GC should be able to collect the DLL handle > knowing that no references to it remain. > > What do you think? It can't work for the following reasons: 1- eln files do not retain the orginal function bytecode. 2- in any point of the code you can get the symbol-function of a defined function and leak it everywhere. We can't technically "swap" functions definitions, the best we do is just redefine them that is set a certain symbol-function (what late load does). The old definitions can always still be used if the referennce is still present somewhere. Even worst the function you want to remove could be active in the stack! One option would be to add a field into the compilation unit object like 'pending_for_removal', each time any of this is unloaded by GC the file is removed if the field suggests that. At the very last when Emacs is closing we go through all the compilation units and remove the files that are still pending. >> No you are right, I don't use Windows since forever, I discovered from >> this thread is not portable. I guess we'll need to rename also here. > > But someone needs to delete the old eln file. Let's say that we use > GetModuleFileNameA() to know if another Emacs instance has decided to ren= ame the > eln file and then we delete it on close if its suffix is ".eln.old". > > This algorithm has a big race condition though. If Emacs1 renames the fil= e after > Emacs2 has checked that it has not been renamed, then the file won't be d= eleted. > If we put the "old eln" in the $TEMP folder this may not be a big issue t= hough. Yes renaming for me here was moving into a temporary folder. This could be a very simple option also for the first problem if we accept we can leave some file there from time to time. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:35:55 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:35:55 +0000 Received: from localhost ([127.0.0.1]:34712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHlz-0004d5-8Y for submit@debbugs.gnu.org; Thu, 14 May 2020 13:35:55 -0400 Received: from mail-oo1-f45.google.com ([209.85.161.45]:41632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHlx-0004cq-Qg for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:35:54 -0400 Received: by mail-oo1-f45.google.com with SMTP id z26so531459oog.8 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 10:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Xw6nok5YDsPDPqlGW3ZB5jQJyMoa+zCjCC3Op48ryak=; b=D6dlmZnn6jw7Ib4wnOLZF0EX2LsNln1GTwrhXL1wX68tDe15SIocOZF1cOF685EiM/ iP7XdunFH+0YBR7K9yJtHhwSxj5KFylHZsN1Ly6W0rNFB275k8ZgQkxY07bDDiwyqSYd VqPZAR52PrkozYos4yzckda19QdFZT9bu1yC54fjd54fY6Es+7zMVD04nSIGzSiiokG1 EmcLDm2THCOCdBDDtnZQ7BHK1Hu/gxGkE07+7ZSK0Q4rFNvlRr5j3F81wq8COgnDGVbP KMvleC5nhLi3KzlbVIy5ek/kJ1AbPQpShcSzphfveWycN+aDV8qCe/c8T5FHJOFQwIoV Nq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Xw6nok5YDsPDPqlGW3ZB5jQJyMoa+zCjCC3Op48ryak=; b=Ga9LGNN3h2xF/JDAzJw1yZn/zmQ25ixbI9HeTdxEBKFCY3fX7vbR+It8rhuhbm4JdX lFk0cqWZ+gdTNljiGbkd3r440sdcr4PWvbuuK7YdkOgg0IfrvuElsri3MAHxDMkguTci 7CVVraLgWJ2j9CkaFsji2Cczbqp8pr8LKdzVRcIJMTrLoKbYzkwzkXrKBX6f8Fnnunvi YhkZKPCmJMy3OyGvwWe+1hr3M+x+abEDe08nL/Ta1J2FAUPZ2j027+ExdXDjx0dKLC4h T44x58W5xAH2XlAzkAAAMjN3N5MCZcdi5nCXyeTiSbG1cbgwyZHsVTbk9Q91QgZC1FB8 gWxQ== X-Gm-Message-State: AOAM531pMzjojZnIMUnlcAMUiRQFBnjD2lItRiy8VZVSdA00rNwkHGLX KiNvHgcgwHNHYx+K9/FNYeKi/8ZdiAJiv8X0bQM= X-Google-Smtp-Source: ABdhPJw6F8+i+tk0Na/+PJyvBFTNn1O4iEqyJivXxtF1bPZLZgeKJ0kvFuZLfLgdzdtGTW6k9fgEWddHt3GBSurqnRQ= X-Received: by 2002:a4a:b346:: with SMTP id n6mr4549840ooo.18.1589477748044; Thu, 14 May 2020 10:35:48 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> In-Reply-To: <83wo5e4e9n.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 14:35:36 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) > Why do you need to check if it's renamed? Just rename always. You need to see if the file has been renamed because someone needs to delete the file > It is not good to move to $TEMP because that one could be on a > different volume, and Windows won't let you do that with a DLL that is > loaded into a process. Touch=C3=A9. El jue., 14 may. 2020 a las 14:28, Eli Zaretskii () escribi= =C3=B3: > > > From: Nicolas B=C3=A9rtolo > > Date: Thu, 14 May 2020 13:50:48 -0300 > > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > > > 1) Call `native-comp-unload`. > > > > 2) This should inspect the eln file and put all the subrs defined in it= on a > > list. This should also copy the original bytecode from the eln file and= store it > > somewhere. > > > > 3) Then `garbage-collect` is called. This should find all references to= the > > subrs in the list and swap them atomically for references to functions > > from the bytecode. > > > > 4) After the previous step the GC should be able to collect the DLL han= dle > > knowing that no references to it remain. > > > > What do you think? > > Do we really need this complexity? > > > > No you are right, I don't use Windows since forever, I discovered fro= m > > > this thread is not portable. I guess we'll need to rename also here. > > > > But someone needs to delete the old eln file. Let's say that we use > > GetModuleFileNameA() to know if another Emacs instance has decided to r= ename the > > eln file and then we delete it on close if its suffix is ".eln.old". > > > > This algorithm has a big race condition though. If Emacs1 renames the f= ile after > > Emacs2 has checked that it has not been renamed, then the file won't be= deleted. > > Why do you need to check if it's renamed? Just rename always. > > > If we put the "old eln" in the $TEMP folder this may not be a big issue= though. > > It is not good to move to $TEMP because that one could be on a > different volume, and Windows won't let you do that with a DLL that is > loaded into a process. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:51:53 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:51:53 +0000 Received: from localhost ([127.0.0.1]:34723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI1R-000575-3W for submit@debbugs.gnu.org; Thu, 14 May 2020 13:51:53 -0400 Received: from mail-oo1-f42.google.com ([209.85.161.42]:37353) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI1P-00056o-Jy for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:51:51 -0400 Received: by mail-oo1-f42.google.com with SMTP id v6so908189oou.4 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V1CzyI/R/uajAVa+NYdMKKJg286AoacqVe/P4GgHxAI=; b=utgoMdo0xU36pqLCCwAreu5gHyxZpHDzgRuydvX0vYIQU93INrLr0/8yhbHOGMjdvv elvWvnAlQzvUFcCFZctLCWdbfeH25GSBpikwtoWiCfWz1x08XpMIkFBzTZlonRx+JytV XIJSxbla/w0puAOpKWLApR6xWs+5qIfJOZgoufE/hSk4BULLumIrS+5HI/p374o6S7fn QJu9wUVzJMGoW6/suZ45hUltmLr9JENXqCsc8/4yOE9Utx/b2NoPjlBRX257p0ePWptG j0L+KhrrFh+wKwc4O+U+4K/cIvbJTYeVIR+5wBx4dM6GYgrDICR1l+E9H5SB4LLGyreL 6hFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V1CzyI/R/uajAVa+NYdMKKJg286AoacqVe/P4GgHxAI=; b=k715ASernl+TzgqbMCI8lLZ6RPA7HNe15stmzrZA8pLOcmCunGIkqEtaVvVMs9Gfkj dOHOFA/BqnJ0tIuP8z9vi+lxDY4NbVYaq262Jk9fe0acOYbFOfQh9anoJAXi+PY7lM6Q WWyCEKVAMCk6q4sr3hGtiL5ftBV0nVIxOGhdfY9XPIeb0h7AQ+Vs1m9MnYEgXUkro/F1 4OiT5ek0Gu96Fo410AFgwB1Rcm8MDNiMmGs657D1oyGU1lhfTZjxfV9191TNeZcHvRdG MOxTTH+CYbfU1TonXFKe9u75q+w2FO435+gkAaZbMVp31CdqYknhJV0D0NhYEsQsUmtd y8gw== X-Gm-Message-State: AOAM533G2MQfYC+Hvh85xxsCb/iZ9RfPPvuoJMfsdC5G0Damfu0GZg9p XJVUVjtFMeRwvOdi+5MbOqZ2kWnjf4DF4KBar6E= X-Google-Smtp-Source: ABdhPJxu2NJuxLZA0v5mcWnU75RV+MOpMnUeYcnFSSyiJzZVwuqF130jS20yHT7Ve5PX+kvHjD9VftKjZX/+kUtdP3I= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr4583507oon.22.1589478705955; Thu, 14 May 2020 10:51:45 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 14:51:34 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > 1- eln files do not retain the orginal function bytecode. That should be easy to change. > in any point of the code you can get the symbol-function of a defined function and leak it everywhere. This is why I said the GC should do it. It should be able to find all references. > We can't technically "swap" functions definitions, the best we do is just > redefine them that is set a certain symbol-function (what late load does). When the GC finds a Lisp_Object that points to a subr we want to unload, it should replace it with one that points to its bytecode equivalent version. > Even worst the function you want to remove could be active in the stack! You are right. I hadn't considered this. It can still be done, but would need to wait until the function finishes. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 13:57:13 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:57:13 +0000 Received: from localhost ([127.0.0.1]:34746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI6b-0005IM-MT for submit@debbugs.gnu.org; Thu, 14 May 2020 13:57:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI6a-0005I8-Qt for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:57:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39240) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZI6U-0004aS-Ex; Thu, 14 May 2020 13:57:06 -0400 Received: from [176.228.60.248] (port=1328 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZI6T-0003nJ-Bo; Thu, 14 May 2020 13:57:06 -0400 Date: Thu, 14 May 2020 20:56:51 +0300 Message-Id: <83r1vm4cyk.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 14:35:36 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 14:35:36 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > Why do you need to check if it's renamed? Just rename always. > > You need to see if the file has been renamed because someone needs > to delete the file If you always rename, then you need to always delete, no? From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:00:34 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:00:34 +0000 Received: from localhost ([127.0.0.1]:34755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI9p-0005Qa-As for submit@debbugs.gnu.org; Thu, 14 May 2020 14:00:34 -0400 Received: from mail-oo1-f44.google.com ([209.85.161.44]:37593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZI9n-0005QL-Vb for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:00:32 -0400 Received: by mail-oo1-f44.google.com with SMTP id v6so914634oou.4 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z/at0/EzuT0JTMwvzPKhwGT72OROGMF11FRLnV89tR4=; b=m7nAajPA7H68ywzLtHzzrxTWLutJLdSOzP65R1EWr8LwfOYYD8RWSCLe1XaSyzto4G vJ0UEv7Bf8NT7ZIJ/zlyLzVt39eq1Cu9znzL2T+k+nqUEdlRvuiRBgfhPbml3UiacRqX OONgvhWyQbOh5gc7eKq9jUTrUsNe6/mUeopGbbYZXxedWmGK0vQ3IUUbs4rzAO/VKBb9 BNwVbw2rvJj2icWjKam6VGD8+iGwW0hFmM9BtO19kG8JKJSye5RqayFLGoOVNbRfRCVf Ib9jCUzHTB517JP+eYNr9pEWKjr4Dj1yIvFCrnasF4LsJml2FiunEusI2IgD/5krXdCA dDQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z/at0/EzuT0JTMwvzPKhwGT72OROGMF11FRLnV89tR4=; b=oCPnG3X/fSZKl0yPnOaSp9SePfQNmyUGzr094cHI3Q8dnOx0wMRJwALqntlPNu6oC2 tNPrzQwWTYfZBtt3adrIZK86E+flXCtIeX3eJqws8XWSKaBK8Tp6U2Ot00Y+17y/wO4+ 7uJ9DifroEQpa3IEq0xQfr1b0w4+6RXBl+Eg/4dj74Tod4ox4ayKMajQeQ6yqbaj8npU 5MS2imZUMfPa8zyyBCVCoHneypdt600I9W/M/BZUvKV0m209k0vhpw5yzme57o6mE0zN lt5REtyCMKTJjgpC1fmHm3oGX6frpdW90HLIZGWArm39oZToTQJJz/HXWYB5MYLdmHAD fNsA== X-Gm-Message-State: AOAM530pCSFznwS6gicMXI5qoJKR4ZeiqGOL4LwcnfOdY1olEVbwtfP2 7rD1fEyAu6WFIEwYZ6nZAhqIESI9jHmgh4CSi64= X-Google-Smtp-Source: ABdhPJzMmA91pqyFLX40g6zyKRsrom4jntAuZCMDqXDxwRUMEtB/9VteIU/Uoyt1Ft2kp2YC5l+doOAxxh5xMsVwuN0= X-Received: by 2002:a4a:b389:: with SMTP id p9mr4601507ooo.84.1589479226173; Thu, 14 May 2020 11:00:26 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> <83r1vm4cyk.fsf@gnu.org> In-Reply-To: <83r1vm4cyk.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 15:00:14 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) > If you always rename, then you need to always delete, no? The Emacs instance that renames the file may not be able to delete the file because another Emacs instance may keep an open handle. It is this last Emacs instance that should delete the file, not the one that renamed it. El jue., 14 may. 2020 a las 14:57, Eli Zaretskii () escribi= =C3=B3: > > > From: Nicolas B=C3=A9rtolo > > Date: Thu, 14 May 2020 14:35:36 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > Why do you need to check if it's renamed? Just rename always. > > > > You need to see if the file has been renamed because someone needs > > to delete the file > > If you always rename, then you need to always delete, no? From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:13:40 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:13:40 +0000 Received: from localhost ([127.0.0.1]:34764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIMW-0005pY-HJ for submit@debbugs.gnu.org; Thu, 14 May 2020 14:13:40 -0400 Received: from mx.sdf.org ([205.166.94.20]:64504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIMT-0005pN-De for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:13:39 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EIDZd5015277 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 18:13:36 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EIDZV1032499; Thu, 14 May 2020 18:13:35 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 18:13:35 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 14:51:34 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> 1- eln files do not retain the orginal function bytecode. > > That should be easy to change. Sure but we don't want to do that because there's no reason to bloat the eln. >> in any point of the code you can get the symbol-function of a defined > function and leak it everywhere. > > This is why I said the GC should do it. It should be able to find all > references. Yes but I can't *remove* objects that are referenced niether swap them. See below. >> We can't technically "swap" functions definitions, the best we do is just >> redefine them that is set a certain symbol-function (what late load does= ). > > When the GC finds a Lisp_Object that points to a subr we want to unload, > it should replace it with one that points to its bytecode equivalent vers= ion. No it cannot, if an object has been tested to say satisfy a predicate you cannot change it for another one. It would break tons of code and make the system totally un-debuggable. >> Even worst the function you want to remove could be active in the stack! > > You are right. I hadn't considered this. It can still be done, but would = need to > wait until the function finishes. Yes, but when are all functions you want to get rid deactivated? Here we are really complexifying a problem that is not. IMO renaming and having a list to do the clean-up are sufficient tools to solve it. --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:30:01 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:30:01 +0000 Received: from localhost ([127.0.0.1]:34774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIcL-0006Kb-3D for submit@debbugs.gnu.org; Thu, 14 May 2020 14:30:01 -0400 Received: from mx.sdf.org ([205.166.94.20]:58695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIcF-0006KJ-7M for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:29:59 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EITsQq016918 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 18:29:54 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EITrpH009515; Thu, 14 May 2020 18:29:53 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> <83r1vm4cyk.fsf@gnu.org> Date: Thu, 14 May 2020 18:29:53 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 15:00:14 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> If you always rename, then you need to always delete, no? > > The Emacs instance that renames the file may not be able to delete the fi= le > because another Emacs instance may keep an open handle. > > It is this last Emacs instance that should delete the file, not the > one that renamed it. Mmmhh, probably also a lock file should be deposed by each Emacs using the file? That way the last session closing could check and remove? --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:30:03 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:30:03 +0000 Received: from localhost ([127.0.0.1]:34778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIcN-0006LV-Ba for submit@debbugs.gnu.org; Thu, 14 May 2020 14:30:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIcL-0006KQ-Rt for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:30:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40044) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZIcG-000355-H6; Thu, 14 May 2020 14:29:56 -0400 Received: from [176.228.60.248] (port=3357 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZIcE-0007RZ-IE; Thu, 14 May 2020 14:29:56 -0400 Date: Thu, 14 May 2020 21:29:39 +0300 Message-Id: <83mu6a4bfw.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 15:00:14 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> <83r1vm4cyk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 15:00:14 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > If you always rename, then you need to always delete, no? > > The Emacs instance that renames the file may not be able to delete the file > because another Emacs instance may keep an open handle. > > It is this last Emacs instance that should delete the file, not the > one that renamed it. Then I guess on Windows we will have to live with the limitation that a .eln file used by another session cannot be recompiled. (I must confess that the idea to use libgccjit and shared libraries for native compilation looks less and less attractive to me due to these complications.) From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:35:15 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:35:15 +0000 Received: from localhost ([127.0.0.1]:34787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIhP-0006WU-E2 for submit@debbugs.gnu.org; Thu, 14 May 2020 14:35:15 -0400 Received: from mx.sdf.org ([205.166.94.20]:57592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIhD-0006Ve-Ra for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:35:04 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EIZ1En029894 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 18:35:01 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EIZ0l6008462; Thu, 14 May 2020 18:35:00 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> <83r1vm4cyk.fsf@gnu.org> <83mu6a4bfw.fsf@gnu.org> Date: Thu, 14 May 2020 18:35:00 +0000 In-Reply-To: <83mu6a4bfw.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 May 2020 21:29:39 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: > (I must confess that the idea to use libgccjit and shared libraries > for native compilation looks less and less attractive to me due to > these complications.) Come on, do we get demotivated that early!? :) :) -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:40:48 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:40:48 +0000 Received: from localhost ([127.0.0.1]:34812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIml-0006iK-VB for submit@debbugs.gnu.org; Thu, 14 May 2020 14:40:48 -0400 Received: from mail-oi1-f180.google.com ([209.85.167.180]:45610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZImk-0006i4-3r for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:40:46 -0400 Received: by mail-oi1-f180.google.com with SMTP id d191so5134871oib.12 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 11:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dvDujnA51aEB7OOzF5Y3r7RiVqgGoCT9TTKgecxOL5E=; b=mL7mUD8KQdwwOSzsJIqKotL+bXWn3Qg2pqAnbXtJA4PjbaVQrthyxZHK+TKX/9zJX9 CgqeoJ99okMSCDVipsrW3bCJxx1GxJB1CV4F3y91ALKAjzi+g4IRDeBtPlRdksYttFZZ uYHM9OY2cb7+eEr1W1XiJ1f12+0QCUXUQW4fddJdRVDm1zsKvrNkrmapMZ6VYjZ5pCUk FuRJ2qzfH741mjE6++mKrlYyqkTIlziD/Z/rIOTUYS+3FUAPrX0Y9QYZwO9wVI22yIO/ Ly4pkFAUwOHtsHIF0uirr5nL0srFfndxVIg/RBg6S9HQ0zbfogMugabRkVQlEkm/1Yul Zp4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dvDujnA51aEB7OOzF5Y3r7RiVqgGoCT9TTKgecxOL5E=; b=KfCni1r+43RpMXyMI+QekUsKi9W2h6pHHVmHTYvh5LBT2s+D254BnpxSs+/MrHnGoV 5gNVmzBTRCCH3iq4N2h6KqsU5Xw4mbXl8IQ0duytYgsEIH13/qxvwtqyr58baWg//dUF xqwh3FzBx4G97ZKj9FGkC7GfjDLd4CeYco0vD5H3YW95YDw6eEvFHaDIoz1q3Jj0Bm27 qGNBTdxEbsiXIs+wODLsKIZVA1ahfZWte6XqmkwpWstojzLoZkcoWjgtXqcfu0Guk/lQ Hcb+ieRFZQwMvoEF6dPXDtOPdwvyHqVix6yrpj2pe79EXLNPQmMQv2tmt7b/7znaDduE CWjA== X-Gm-Message-State: AOAM5307h25BzxnmB8g+abrqaVy6VF23HiyWaGJklhT3EwVk4oE7BIMi Yy85Ggow9TaMmadjNPyzI6GX9uJI3YEwvNpTTeA= X-Google-Smtp-Source: ABdhPJz+MvCoRK1NP7PEm1JRAPJn8NHBSoN+O0nxB/s/BjXKbLzt7MR04m/6nehk9dzC6uGNP8C5LKQ0kXemfWL6efY= X-Received: by 2002:aca:e104:: with SMTP id y4mr2178551oig.120.1589481640270; Thu, 14 May 2020 11:40:40 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 15:40:28 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > Here we are really complexifying a problem that is not. IMO renaming > and having a list to do the clean-up are sufficient tools to solve it. You're right. I just think that renaming and a list do not guarantee that w= e always delete the files when we should. Consider this case: * Emacs1 and Emacs2 are two Emacs instances that load the same foo.eln file. * Emacs1 decides to recompile foo.el. To do that it renames foo.eln to foo.eln.old. It creates a new foo.eln and tries to delete foo.eln.old. It fails because Emacs2 has an open handle to it. * When Emacs2 closes it realizes that foo.eln has been renamed to foo.eln.o= ld and deletes it. That is the good case. If we are unlucky this is what may happen: * Emacs2 begins to close. It checks that foo.eln has not been renamed. Ther= efore it does not delete it. But it does not call FreeLibrary yet. * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails si= nce Emacs2 has an open handle. * Emacs2 finally calls FreeLibrary() and closes. In this case we are left over with a stale foo.eln.old. I don't think we ca= n have a race free algorithm. We could add a "GC" step to `load`, where it tries to find stale .eln.old files and removes them. Nicolas. El jue., 14 may. 2020 a las 15:13, Andrea Corallo () escribi= =C3=B3: > > Nicolas B=C3=A9rtolo writes: > > >> 1- eln files do not retain the orginal function bytecode. > > > > That should be easy to change. > > Sure but we don't want to do that because there's no reason to bloat the > eln. > > >> in any point of the code you can get the symbol-function of a defined > > function and leak it everywhere. > > > > This is why I said the GC should do it. It should be able to find all > > references. > > Yes but I can't *remove* objects that are referenced niether swap them. > See below. > > >> We can't technically "swap" functions definitions, the best we do is j= ust > >> redefine them that is set a certain symbol-function (what late load do= es). > > > > When the GC finds a Lisp_Object that points to a subr we want to unload= , > > it should replace it with one that points to its bytecode equivalent ve= rsion. > > No it cannot, if an object has been tested to say satisfy a predicate > you cannot change it for another one. It would break tons of code and > make the system totally un-debuggable. > > >> Even worst the function you want to remove could be active in the stac= k! > > > > You are right. I hadn't considered this. It can still be done, but woul= d need to > > wait until the function finishes. > > Yes, but when are all functions you want to get rid deactivated? > > Here we are really complexifying a problem that is not. IMO renaming > and having a list to do the clean-up are sufficient tools to solve it. > > -- > akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:49:04 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:49:04 +0000 Received: from localhost ([127.0.0.1]:34816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIul-0006yp-S8 for submit@debbugs.gnu.org; Thu, 14 May 2020 14:49:04 -0400 Received: from mx.sdf.org ([205.166.94.20]:55023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIuj-0006yG-5e for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:49:01 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EImwmi004782 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 18:48:58 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EImw1U017679; Thu, 14 May 2020 18:48:58 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 18:48:58 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 15:40:28 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Here we are really complexifying a problem that is not. IMO renaming >> and having a list to do the clean-up are sufficient tools to solve it. > > You're right. I just think that renaming and a list do not guarantee that= we > always delete the files when we should. > > Consider this case: > > * Emacs1 and Emacs2 are two Emacs instances that load the > same foo.eln file. > > * Emacs1 decides to recompile foo.el. To do that it renames foo.eln to > foo.eln.old. It creates a new foo.eln and tries to delete foo.eln.old. = It > fails because Emacs2 has an open handle to it. > > * When Emacs2 closes it realizes that foo.eln has been renamed to foo.eln= .old > and deletes it. > > That is the good case. > > If we are unlucky this is what may happen: > > * Emacs2 begins to close. It checks that foo.eln has not been renamed. Th= erefore > it does not delete it. But it does not call FreeLibrary yet. > > * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails = since > Emacs2 has an open handle. > > * Emacs2 finally calls FreeLibrary() and closes. > > In this case we are left over with a stale foo.eln.old. I don't think we = can > have a race free algorithm. > > We could add a "GC" step to `load`, where it tries to find stale .eln.old > files and removes them. > > Nicolas. I see. But I suspect it could work just if each Emacs sessions depose a file to signal is activelly using a certain .eln. The last session can retrive the current filename of the handle and delete it. Do you think it works? --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 14:59:15 2020 Received: (at submit) by debbugs.gnu.org; 14 May 2020 18:59:15 +0000 Received: from localhost ([127.0.0.1]:34844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ4c-0007KA-OP for submit@debbugs.gnu.org; Thu, 14 May 2020 14:59:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:37598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ4b-0007K3-0P for submit@debbugs.gnu.org; Thu, 14 May 2020 14:59:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZJ4a-0006wD-Mt for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 14:59:12 -0400 Received: from ciao.gmane.io ([159.69.161.202]:41780) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZJ4X-0001EA-L3 for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 14:59:12 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jZJ4U-000HZW-2K for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 20:59:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Achim Gratz Subject: Re: bug#41242: Port feature/native-comp to Windows Date: Thu, 14 May 2020 20:59:00 +0200 Organization: Linux Private Site Message-ID: <87h7wigx6z.fsf@Rainer.invalid> References: <834ksi60zn.fsf@gnu.org> <83wo5e4e9n.fsf@gnu.org> <83r1vm4cyk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:htRtwvS1OhDfK/ejnqTeggAonw8= Received-SPF: pass client-ip=159.69.161.202; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/14 14:59:06 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit 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: -2.1 (--) Andrea Corallo writes: > Mmmhh, probably also a lock file should be deposed by each Emacs using > the file? That way the last session closing could check and remove? You might be interested in this: https://archive.fosdem.org/2018/schedule/speaker/michael_haubenwallner/ (Gentoo PRefix running on Cygwin, which means that in-use libraries need to be replaceable.) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:00:29 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:00:29 +0000 Received: from localhost ([127.0.0.1]:34852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ5i-0007iO-2W for submit@debbugs.gnu.org; Thu, 14 May 2020 15:00:29 -0400 Received: from mail-oi1-f182.google.com ([209.85.167.182]:37043) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ5g-0007ai-4H for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:00:20 -0400 Received: by mail-oi1-f182.google.com with SMTP id r25so25491416oij.4 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 12:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PebNgA5ix12x1newgDNNX9wVoMovlKTL+8CEWd92nwY=; b=lGh872IccDcxGd9J5JVD/PR2t5NUI1KMKCRF4G7YKk3Zg5w6E85jBURJQxos38APJk G8LzxL1HvF25di/iJVjtU1EzvRNXu0Bo1iqhhgnBotwmyLZypPfLGJk2gLLM+E7K4idc 6OgIDfCm7y+TQ3BiA818FXYU3PjZkfGq6b9Nyv4xfy91CMHeu6vWm7n4d7NR0t3cl56U H3T0ndFinzDPv3Q4W+9kPG6fVYgTHN+LfH7FH3s83PSVVuNW2erUw0A1lxLWguPqHkOE U2ZztTXqmEIos8sPHNNq6AqNYujm/i/Wdgmk6XQXlup7ETojV7Y2opacgjErKGyh5mAI 62Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PebNgA5ix12x1newgDNNX9wVoMovlKTL+8CEWd92nwY=; b=mN3A+KDwyyiPRxvZi37C33EL5BOxQPmDvUhHUOZzXz5Qk1W8xMsLHB+rqXeHym7UIm nYAB6oCsRtRS6y3A0elmgLPgCVDeocen/YcszvrHH8uyOFI6aq62GpWMHFAHI8/IeuaF UzDifxZgXIaLyyz+hg+g7qY0UJU4kiUbyU6jkGqvHfd1ehcRcVUhUFmYr0FnB4IgSdQg PeUj5u43nYNtbFKhAj20hivF4Z8vxg7aittzY99rhRHVjDi/A9kCEZJhpcWFEarCoLrT 0E4MXKbyl6uDejMHIZUH2e6HIOnKf+nO1kCp2EqCLHQ0bIbF9KDECkXDO2PmxR7E2ByX aEzA== X-Gm-Message-State: AGi0PuaA1cTHtvmrqWcMUAWkTaQZtTDXX+fpcm9fYdY5s7w27LJdlPSs HQzm8V3iCW3R8aSM4GBVh85anmoMKgwembweAiH9K5v727aJjQ== X-Google-Smtp-Source: ABdhPJyXzZj//rxJ+kbtEotqJnNG7elpK1M6kiiI7/SLKHS4vul8TQ6+OqBLeRBcs51GVqlizA6SJfyRbQ6OwnaRmZk= X-Received: by 2002:aca:e104:: with SMTP id y4mr2230020oig.120.1589482813690; Thu, 14 May 2020 12:00:13 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 16:00:02 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > Do you think it works? I don't know. What do you have in mind? Another option: We could use a global mutex shared between all Emacs processes. https://docs.microsoft.com/en-us/windows/win32/sync/mutex-objects They would have to acquire that mutex before any operation using eln files. This is a complicated solution, though. Nicol=C3=A1s. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:00:43 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:00:43 +0000 Received: from localhost ([127.0.0.1]:34856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ63-000844-G1 for submit@debbugs.gnu.org; Thu, 14 May 2020 15:00:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJ60-0007wW-S1 for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:00:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40562) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZJ5v-0001zi-9f; Thu, 14 May 2020 15:00:35 -0400 Received: from [176.228.60.248] (port=1309 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZJ5t-0003Ap-Hb; Thu, 14 May 2020 15:00:34 -0400 Date: Thu, 14 May 2020 22:00:19 +0300 Message-Id: <83k11e4a0s.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 15:40:28 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 15:40:28 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > * Emacs1 and Emacs2 are two Emacs instances that load the > same foo.eln file. > > * Emacs1 decides to recompile foo.el. To do that it renames foo.eln to > foo.eln.old. It creates a new foo.eln and tries to delete foo.eln.old. It > fails because Emacs2 has an open handle to it. > > * When Emacs2 closes it realizes that foo.eln has been renamed to foo.eln.old > and deletes it. How can Emacs2 realize that foo.eln was renamed? > If we are unlucky this is what may happen: > > * Emacs2 begins to close. It checks that foo.eln has not been renamed. Therefore > it does not delete it. But it does not call FreeLibrary yet. > > * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails since > Emacs2 has an open handle. > > * Emacs2 finally calls FreeLibrary() and closes. > > In this case we are left over with a stale foo.eln.old. I don't think we can > have a race free algorithm. We will have to tell users not to do that on Windows. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:13:56 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:13:56 +0000 Received: from localhost ([127.0.0.1]:34903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJIq-0001TI-BY for submit@debbugs.gnu.org; Thu, 14 May 2020 15:13:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJIo-0001T7-TG for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:13:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40948) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZJIj-0005S5-1T; Thu, 14 May 2020 15:13:49 -0400 Received: from [176.228.60.248] (port=2136 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZJIi-0007YG-B8; Thu, 14 May 2020 15:13:48 -0400 Date: Thu, 14 May 2020 22:13:31 +0300 Message-Id: <83h7wi49es.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 15:40:28 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 15:40:28 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails since > Emacs2 has an open handle. > > * Emacs2 finally calls FreeLibrary() and closes. > > In this case we are left over with a stale foo.eln.old. I don't think we can > have a race free algorithm. When Emacs1 fails to delete foo.eln.old, it could record the file's deletion to be attempted again when it exits. That won't solve all the cases, but it will solve some of them. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:15:42 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:15:42 +0000 Received: from localhost ([127.0.0.1]:34928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJKX-0001ZJ-Nf for submit@debbugs.gnu.org; Thu, 14 May 2020 15:15:41 -0400 Received: from mx.sdf.org ([205.166.94.20]:50658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJKV-0001ZA-NI for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:15:40 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EJFcOL023021 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 19:15:38 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EJFci8031307; Thu, 14 May 2020 19:15:38 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 19:15:38 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 16:00:02 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Do you think it works? > > I don't know. What do you have in mind? Not much more than that. As you said the problem is to decide who has the duty to remove the file at last. If each Emacs deposes a file says .foo.eln-pidxxx for the whole time is using foo.eln should be easy for the last Emacs to understand it is really the last and has to do the clean-up in the case foo.eln was renamed in foo.eln*whatever I think it could work. (?) > Another option: > > We could use a global mutex shared between all Emacs processes. > https://docs.microsoft.com/en-us/windows/win32/sync/mutex-objects > > They would have to acquire that mutex before any operation using eln file= s. > This is a complicated solution, though. > > Nicol=C3=A1s. > --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:17:08 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:17:08 +0000 Received: from localhost ([127.0.0.1]:34932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJLv-0001c6-2f for submit@debbugs.gnu.org; Thu, 14 May 2020 15:17:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJLt-0001bX-I5 for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:17:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41052) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZJLo-0006Fk-Bd; Thu, 14 May 2020 15:17:00 -0400 Received: from [176.228.60.248] (port=2333 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZJLl-00081V-Un; Thu, 14 May 2020 15:16:59 -0400 Date: Thu, 14 May 2020 22:16:43 +0300 Message-Id: <83ftc2499g.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 16:00:02 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 16:00:02 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > We could use a global mutex shared between all Emacs processes. > https://docs.microsoft.com/en-us/windows/win32/sync/mutex-objects > > They would have to acquire that mutex before any operation using eln files. > This is a complicated solution, though. If we want a mutex, we can use the offending .eln file as that mutex: if deletion fails, the mutex is taken. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:37:08 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:37:08 +0000 Received: from localhost ([127.0.0.1]:34960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJfI-0002Bs-Nc for submit@debbugs.gnu.org; Thu, 14 May 2020 15:37:08 -0400 Received: from mail-oo1-f48.google.com ([209.85.161.48]:32874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJfG-0002BL-QE for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:37:07 -0400 Received: by mail-oo1-f48.google.com with SMTP id q6so376685oot.0 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 12:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=poBlW+4tMf+LrghAfUKgHuuApJnKJaYMYL9D7iIwR78=; b=cIGYH6p2an1c82KkrfVB2Srhc8hqs9wZta1AtGqPMewKhpx/srhxv9/MKVgaUrW/iu JrSDekKmIiC2g/aLcCq8lAGdjPQSdgp/wV4R74u44CnBZknS/xaRe4bwNunKz8FQhCbz dWHNCcBe1NXidQmygiQt/67qrvAgDIDn7WxR26VzFNrFp0xLEA8wTU+d2q0DgESzVYaK 49GSXNRA/CDHXImREoIlY/05QTdoSf+ZdooXLw5I+MH3/G/8WwRTo6qgnFp7a9hU7Ixq VrC51vM7oMEWxUoFwSuNvo8xZnZUJuHQ+jHFJFJg+Z2G+3tiVcXX9XJzCScveBjpdvrC +xuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=poBlW+4tMf+LrghAfUKgHuuApJnKJaYMYL9D7iIwR78=; b=X1VvpIZsqMFlLWMXhUEm3qqYY+IdwPIgTgmd9bok1td4nLSF4wfcIN/cgUePJgH89n EWSV2aPaFieGL+A2pWHPWlo/mFUOM1+KuwRcr0Xs27k7CUvMPA+6tbwlFvcVo0U94ZYj zNl1oDJn4ZNUl6IXxXgSlLxscXpRwL/7W+/UpLBqg8FAV53fUWBpWEW1+aPXKzFvY/bh ZiXADH95EKPsk7rAI2RqGV2cskditNSHiVpwiwojO5+iSgdZOzU5j1AB/MG29EzcBXF6 eK5C3Nhz3Bu9aQLCT03cqeRuavqjaib8mUrpR1jN/i+DChYNM6AVp8AQ8Z39v1/sxCNF DSkw== X-Gm-Message-State: AOAM533SpX8YoxChzhWGpGfr9sqbadG0j/OWJMU7VwpUPz2tVFWxvUff Q7SW/MBSzTDS2Qp49oLz8LmLhGiQ8vpngMEAs0s= X-Google-Smtp-Source: ABdhPJyuvQQHIWG/dCHfAG7Xon7CJ2+subVeWubEc8045Z+LKIdoJv4unrHoGgc03EKXQOppB0+lO6eiNIi+d2kSdQI= X-Received: by 2002:a4a:b389:: with SMTP id p9mr4951269ooo.84.1589485021118; Thu, 14 May 2020 12:37:01 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> In-Reply-To: <83k11e4a0s.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 16:36:49 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) > How can Emacs2 realize that foo.eln was renamed? Using GetModuleFileNameA https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:48:25 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:48:25 +0000 Received: from localhost ([127.0.0.1]:34969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJqD-0002WA-17 for submit@debbugs.gnu.org; Thu, 14 May 2020 15:48:25 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:36695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJqC-0002Vr-4N for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:48:24 -0400 Received: by mail-ot1-f47.google.com with SMTP id t3so45345otp.3 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 12:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2dpWp/o2wCqOzUvO5pvEtb1wdvn+jEorO8zr63ottQc=; b=TsZt/b6A2e60yi3Fc6MDG7SwaljAhlKvSrKxBYYGMob+yye0lBqugTf70NKUmkKp/m 8uCWiGrrQzzQLKlaoES3gbrEebZ2VunybrEnAuCqSfYKFqvHvx+KBpYt6Opiktq4z/vW M1kkJW9728ngl3urMXu6mpgIlkMVt3MF90y7iPembasDu+UNsp87ryS8ZTqIk7o/lulo QQcvY9a1d6NyHW+RR4TSvrzqjidujv7jjgrFWi3PWGOkQyI5JC53Fn0FSqk3I+BpnSis 55ADyeGMpUFsZ1GnJDaCdfcoA2e9jwm7Itnbqzke6vWSVW5kYADzz/X1L030c4jtg4xf XOIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2dpWp/o2wCqOzUvO5pvEtb1wdvn+jEorO8zr63ottQc=; b=Q0owqAaj2PfKPFHqo47vP6DGALDxPSWxYM6Rmhi1qT8Np4L37JU7/6ZjNceWxXxeEP VQ28IvY15DUAKUe801hWFZNiaD9cSEXWlVlJ2+EUoiQ7Qge17VYdjYLjCyFvjHgp8wPy weV3XCJ3b6S4EKcXW/F01q2RQcacOhqf5xIWI42kDOWs9MfBI74QdOF2Sy5IdjAEexys 9rl1rdhjfhf8cfnVPC4lytys5BVljRZc68mEwS1EZ67XkX98O8qwcxEba7oG2ll0T4R8 1nFkfxxYrW3uLyVHkz0VRZ2ERnbfYlboItRyinvdnrCuQxfu+IxZxwf93G9PDakVpgED Pazg== X-Gm-Message-State: AOAM5325B88Hv36f6au7gqTEl1xMw2Pimin6logBRhSTUlD/ZuJ2I8ld 0zDaTC57tH2GjFCXFEccP+eUiezpt4TkHV05vVo= X-Google-Smtp-Source: ABdhPJzx/rcjd7Ud6juaHjDWGNyNjiYRpaahQ0XV/GsgY2Pk/V6pfajm6Z1EwCKvG+qdMdrvfedg5AVgfzEEfYwlMFY= X-Received: by 2002:a9d:191:: with SMTP id e17mr4619827ote.193.1589485698414; Thu, 14 May 2020 12:48:18 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 16:48:06 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > As you said the problem is to decide who has the duty to remove the file > at last. If each Emacs deposes a file says .foo.eln-pidxxx for the > whole time is using foo.eln should be easy for the last Emacs to > understand it is really the last and has to do the clean-up in the case > foo.eln was renamed in foo.eln*whatever That file would be create when opening foo.eln, but when Emacs is closing we don't know what file it refers to: - foo.eln - foo.eln.old - foo.eln.old2 - foo.eln.oldN These last files could be created if foo.eln.old exists at the time of renaming. From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 15:58:13 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 19:58:13 +0000 Received: from localhost ([127.0.0.1]:34973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJzg-0002ow-UB for submit@debbugs.gnu.org; Thu, 14 May 2020 15:58:13 -0400 Received: from mx.sdf.org ([205.166.94.20]:57696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZJzd-0002oj-MO for 41242@debbugs.gnu.org; Thu, 14 May 2020 15:58:12 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EJw8RZ017204 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 19:58:08 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EJw8xw022615; Thu, 14 May 2020 19:58:08 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 19:58:08 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 16:48:06 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> As you said the problem is to decide who has the duty to remove the file >> at last. If each Emacs deposes a file says .foo.eln-pidxxx for the >> whole time is using foo.eln should be easy for the last Emacs to >> understand it is really the last and has to do the clean-up in the case >> foo.eln was renamed in foo.eln*whatever > > That file would be create when opening foo.eln, but when > Emacs is closing we don't know what file it refers to: > - foo.eln > - foo.eln.old > - foo.eln.old2 > - foo.eln.oldN > > These last files could be created if foo.eln.old exists at the time of re= naming. Yes, but I think we could say: the last Emacs closing that used any file that was (at a certain point in life) foo.eln removes all the old foo.eln.* If is the last using any of the foo.eln* it can do that safely no? --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 16:16:30 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 20:16:30 +0000 Received: from localhost ([127.0.0.1]:35013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKHN-0003PL-UX for submit@debbugs.gnu.org; Thu, 14 May 2020 16:16:30 -0400 Received: from mail-ot1-f42.google.com ([209.85.210.42]:44734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKHH-0003N5-B6 for 41242@debbugs.gnu.org; Thu, 14 May 2020 16:16:23 -0400 Received: by mail-ot1-f42.google.com with SMTP id j4so73632otr.11 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 13:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9Vx55hgaR3yrZ9Jj/ALL0PDDeXgP6/vID2ufUe7VjYs=; b=Suup2cWSNnM5gY7v5lDderKOVsfyBLJqn1heYs78kf82nQxW58t5veXZK1z7GvKls2 s2s4k6owl13otyutcEz+Wp/7Y0cKSzFBHNKg2dGATf5ffytLfHpAT+Ti1S09VsTPvhlU HCWrS8sfLzyMH4QD86IsJmmDwrUqdWvO5GUbp5OYyD6YiMH3ULsX/8XhimVSxVcXnZRe TohYzfUN+ETDk/6FdMw8z2DpYOpa52Vr7xdD8xLFqLXHGiUPINFThAInpq5bwqBGoRKh X2JiJltNSSpwfg0OJB1f5VlYoiUrjNRgA1KWKCtBKb/wQ8hvzeVxA7Amhu3SXs41PsCX 0I5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9Vx55hgaR3yrZ9Jj/ALL0PDDeXgP6/vID2ufUe7VjYs=; b=RoqYaDMBF6Ic2647YiJJG5mZ1QEkY04ZDNskPfuGw2AS4ITd8K0KOR+le2Htenu5ZM JJkIrQ3wSobIO062wHyJwnQxtpT2i5e1paQemUQy9alqG7h4v4tL5FgHzAEX4d5IIVIO +VykCzVzH+S1oWRM8iyA+pcIqc2TY7/M6rhtpMsmweb2r5BL6SsIsTDZIME5KbnvTmIv FaLzvw6WeTMyy2tN6hGyYX5QXo0TDf6xSY9Gb9aF0v7Eth3o3Kw3QjIZugaubR+TP/Wm IySxY3fD3XD1Mzsq0yQHve8Wjy2wAl3dX+CGapKR4C4lNLcGTqtV7gZoSrje1NwqJc+q w3QQ== X-Gm-Message-State: AOAM530GAx34CdAwUCQnjUyV7luPhqb1w3uN2iZTJXr2oBkV93oDZ6XR 4sBlRjOtfcR7VuvmN/0hka/LWtrfH/bhOmoU+0c= X-Google-Smtp-Source: ABdhPJwRRRntHQzwR7YqpYScpVQdmva5T0NYogH7+NZIcHbeQtPiYalKG48Nc5EQL3irE+Yo37JyBozOgWl7p19sADo= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr4922214oti.202.1589487377519; Thu, 14 May 2020 13:16:17 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 17:16:05 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > Yes, but I think we could say: the last Emacs closing that used any file > that was (at a certain point in life) foo.eln removes all the old > foo.eln.* I think this would work :). We could even remove the pid file. Just do the equivalent of `rm $ELN.old*` after FreeLibrary(). If the deletion fails then that means that another Ema= cs has loaded that file. It would take of files left over from crashes too. We would need to change `package-delete` though. It would no longer fully delete the directory. Maybe other functions in `package.el` would need to be updated to deal with these changes. Nicolas. El jue., 14 may. 2020 a las 16:58, Andrea Corallo () escribi= =C3=B3: > > Nicolas B=C3=A9rtolo writes: > > >> As you said the problem is to decide who has the duty to remove the fi= le > >> at last. If each Emacs deposes a file says .foo.eln-pidxxx for the > >> whole time is using foo.eln should be easy for the last Emacs to > >> understand it is really the last and has to do the clean-up in the cas= e > >> foo.eln was renamed in foo.eln*whatever > > > > That file would be create when opening foo.eln, but when > > Emacs is closing we don't know what file it refers to: > > - foo.eln > > - foo.eln.old > > - foo.eln.old2 > > - foo.eln.oldN > > > > These last files could be created if foo.eln.old exists at the time of = renaming. > > Yes, but I think we could say: the last Emacs closing that used any file > that was (at a certain point in life) foo.eln removes all the old > foo.eln.* > > If is the last using any of the foo.eln* it can do that safely no? > > -- > akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 16:29:51 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 20:29:51 +0000 Received: from localhost ([127.0.0.1]:35038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKUI-0003nJ-Tx for submit@debbugs.gnu.org; Thu, 14 May 2020 16:29:51 -0400 Received: from mx.sdf.org ([205.166.94.20]:49601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKUH-0003nA-JO for 41242@debbugs.gnu.org; Thu, 14 May 2020 16:29:50 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EKTldC013422 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 20:29:47 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EKTlko007628; Thu, 14 May 2020 20:29:47 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> Date: Thu, 14 May 2020 20:29:47 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 14 May 2020 17:16:05 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Yes, but I think we could say: the last Emacs closing that used any file >> that was (at a certain point in life) foo.eln removes all the old >> foo.eln.* > > I think this would work :). Very good > We could even remove the pid file. Just do the equivalent of `rm $ELN.old= *` > after FreeLibrary(). If the deletion fails then that means that another E= macs > has loaded that file. It would take of files left over from crashes too. Ah okay I thought (probably had to read better) something goes wrong if you remove when you should not. Then is even easier yes! > We would need to change `package-delete` though. It would no longer fully > delete the directory. Maybe other functions in `package.el` would need > to be updated to deal with these changes. If you diff the full branch I had to adjust few thing in Emacs too to have it working, I believe is expected. You'll check for the presence of the native compiler in Lisp with the function you've introduced in one of your patches. I believe also that the renaming mechanism should be transparent on all posix where is not necessary. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Thu May 14 16:34:43 2020 Received: (at 41242) by debbugs.gnu.org; 14 May 2020 20:34:43 +0000 Received: from localhost ([127.0.0.1]:35050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKZ0-0003xK-Q9 for submit@debbugs.gnu.org; Thu, 14 May 2020 16:34:42 -0400 Received: from mail-oi1-f182.google.com ([209.85.167.182]:43821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZKYy-0003x3-Td for 41242@debbugs.gnu.org; Thu, 14 May 2020 16:34:41 -0400 Received: by mail-oi1-f182.google.com with SMTP id i22so210250oik.10 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 13:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vmZr4WeZHK2xD8kTSCW/UX0ryrutGYhjLoLc0aV3Sb4=; b=YqEBiOXSeMa+eFi2KLWCsbk4ExA63ly5oHUY18//unAQI3ELWwo2cLxXnSsF7YZkpn aE336SgT6uPJrhBF1Km/hdib68WDKdjcprX3EwW/fkIQUozbYfvosPEEPmDau2M1iYfR WMx93Nm+k4R09Ah+aKoxsGwSINlGBY0MY4k9OHRgCykMahsUE6HO999BHYZpX+pAu7bd dyb/l0r5Es4LzxD/EzGns1Q6AmhMhiLbpHT1VX61mN18PtqWp96KWmfDjMoLQYjFXODQ WGxhEFhZrKw+itYt6tQtBpFq/UNHtlHl8fLpDIF3oM2r2knLzfY0sgOQWcDzDPjHsqM6 QrlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vmZr4WeZHK2xD8kTSCW/UX0ryrutGYhjLoLc0aV3Sb4=; b=PNd4C0p4++/dH0GWy3GnwMgVT4f9oMJ5ifAfCPLyHjU4FyZ0B+tTzP0HtXUIKY/NLS vP1TAib6croWoGQvJIJ2Q4Sw2WmTncqgBkGPXXgoqysMoveXtXL3FYjs5rKIurDThF6w 27lwQbQHjSDFd+zF2ALByu9eR1s4oBIsTrypwM+003axmbvHO1ILIrjxGOcWyPWqFKpp 8lK+BD8rH91xn2Q4mfXsuKJyjoAney3sSHrDVBBXrXeOZKiK37x5icJS59t5ljR6LFHG wY4cd8IOqzNm+3JkmEUxAZ4u4ZTyD4Be/RwEwB/5oFGP6icdZVXHsRKWrvF41n3b9SfT QpNQ== X-Gm-Message-State: AOAM532TpeoeWxDqTS8nq7/xWFKEQkolMkGeLsvwPqE1FtkziwCIn1Hz vSTAP+UY/7qMH2nnhPShFst4P+HmtwRcNhwgv+8= X-Google-Smtp-Source: ABdhPJyLF068bRsRI6AuclevTAug2dqQso6EOD/DR5IsW6ko971LAVXnoeauZ1sqbQXrG2+i7Efmwbog4WJSB0WMluM= X-Received: by 2002:a54:4701:: with SMTP id k1mr905583oik.175.1589488475208; Thu, 14 May 2020 13:34:35 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 14 May 2020 17:34:23 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > We would need to change `package-delete` though. It would no longer fully > delete the directory. Maybe other functions in `package.el` would need > to be updated to deal with these changes. Maybe not. We could move the .eln to the parent of the argument to `delete-directory`. For example move elpa\28.0\develop\company-20200510.1614\eln-x86_64-w64-mingw32-683c5a1b96c51930\company.eln to elpa\28.0\develop\company.eln.old The code to find the .eln.old files to delete would have to check if it is a package it is dealing with and search for .eln.old files in an upper folder. Nicolas. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 02:08:26 2020 Received: (at 41242) by debbugs.gnu.org; 15 May 2020 06:08:26 +0000 Received: from localhost ([127.0.0.1]:35691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZTWD-0005xN-QL for submit@debbugs.gnu.org; Fri, 15 May 2020 02:08:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZTWB-0005x8-8c for 41242@debbugs.gnu.org; Fri, 15 May 2020 02:08:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51869) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZTW5-0005LJ-DW; Fri, 15 May 2020 02:08:17 -0400 Received: from [176.228.60.248] (port=2363 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZTW4-0004Q6-TU; Fri, 15 May 2020 02:08:17 -0400 Date: Fri, 15 May 2020 09:08:04 +0300 Message-Id: <83blmp4tob.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 16:36:49 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 16:36:49 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > How can Emacs2 realize that foo.eln was renamed? > > Using GetModuleFileNameA > https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea Does that reflect renaming _after_ the library was loaded? From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 02:10:51 2020 Received: (at 41242) by debbugs.gnu.org; 15 May 2020 06:10:51 +0000 Received: from localhost ([127.0.0.1]:35695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZTYZ-00060o-7k for submit@debbugs.gnu.org; Fri, 15 May 2020 02:10:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZTYX-00060a-DH for 41242@debbugs.gnu.org; Fri, 15 May 2020 02:10:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51884) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZTYS-0005kN-6J; Fri, 15 May 2020 02:10:44 -0400 Received: from [176.228.60.248] (port=2511 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZTYR-0004di-GZ; Fri, 15 May 2020 02:10:43 -0400 Date: Fri, 15 May 2020 09:10:30 +0300 Message-Id: <83a7294tk9.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Thu, 14 May 2020 16:48:06 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Thu, 14 May 2020 16:48:06 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > > As you said the problem is to decide who has the duty to remove the file > > at last. If each Emacs deposes a file says .foo.eln-pidxxx for the > > whole time is using foo.eln should be easy for the last Emacs to > > understand it is really the last and has to do the clean-up in the case > > foo.eln was renamed in foo.eln*whatever > > That file would be create when opening foo.eln, but when > Emacs is closing we don't know what file it refers to: > - foo.eln > - foo.eln.old > - foo.eln.old2 > - foo.eln.oldN > > These last files could be created if foo.eln.old exists at the time of renaming. We could try deleting all of them. Those that are still in use will not be deleted. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 08:33:50 2020 Received: (at 41242) by debbugs.gnu.org; 15 May 2020 12:33:50 +0000 Received: from localhost ([127.0.0.1]:36163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZXB-0002qv-W3 for submit@debbugs.gnu.org; Fri, 15 May 2020 08:33:50 -0400 Received: from mail-oi1-f174.google.com ([209.85.167.174]:41641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZXA-0002qj-JT for 41242@debbugs.gnu.org; Fri, 15 May 2020 08:33:48 -0400 Received: by mail-oi1-f174.google.com with SMTP id 19so2043042oiy.8 for <41242@debbugs.gnu.org>; Fri, 15 May 2020 05:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rI6KnjM3DdU6QcXXbnwQX9E06n6tvLx40UCZFzn2l/I=; b=kaydwiZAF8WTMyPzVU0pckWI/0inL5CVCzlRa44YS7QzsAhVhZloav3sZ4oH/GQxe4 XWjIyvUEeQDXdpRAiiplEuiKe9slQXP+vMSVBfjsd5yKS3uhl3iRqsgfg3HTplPoh7HR u7r/geEYbSkaKZl1z+2a/hbq81Blg+XY0k5O0GurJCW83ngCHIwfBvwgKXS56rBOnmMg 6uNcyJb4T8HVnN71qaJlTXk4y3Hl+GmclawoK5zAz3OtP8uBLaHwmyDW9bYxRMmRRA24 Frj2Nur+Jc3JEWbHQfoSUaIQ6J38eaFWV3SLIKi+22HeNpx1Jl0xmIfreJx4DLQVS2rQ nmew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rI6KnjM3DdU6QcXXbnwQX9E06n6tvLx40UCZFzn2l/I=; b=QDWnthaUh5o21KzRNKAEDqlbOaptjXkskBCLkjONa7VIpadAs6TNHxCrnFON+uho6/ 5KWy3EEzRqfa/V7pbbqbc5RhWEpraTuisOXFx+LpA1cvS1K+vX/QwtiyI6EtQJeuxM60 9kwGGSYdcenHrszjABY616KninHt8lO1Pzqq4hKeee96cCySgvJZ3pH4lMoX6la2wG/l xrJpWkTv/LCo7sdVhmunJPaup0Rl6p3QV7tm8EJ8J1iHKEZryxAxqeU9N5F2zPZ+Jeet iMngqM7Lv2wiNIg3Nn/A8gJXWqHP84fbbwb3p1AgA3H6E9R2j6tYX8CYjDHHbaftO25q agaA== X-Gm-Message-State: AOAM531S2qprRvbWcKDQQQ6BI2dwscky/YOqhEWE161ghYdYRMfO1jeY LnJP8dvPAB/syc9wKhBJF3igni8sy/ereweOeO8= X-Google-Smtp-Source: ABdhPJyMeu9htetAQQps14vy0Xqbu+CivnjYA+f7XNeYb6edUiH5Fl30TMbH+SPzryUhTLzTHiJZhABSLDEg4qS8ets= X-Received: by 2002:a54:4701:: with SMTP id k1mr1947760oik.175.1589546022938; Fri, 15 May 2020 05:33:42 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> In-Reply-To: <83blmp4tob.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Fri, 15 May 2020 09:33:32 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) > Does that reflect renaming _after_ the library was loaded? I get that idea from the documentation. I haven't actually tested it myself. The ProcessExplorer utility can show the name of the loaded DLLs of a process. If I rename one the changed name will show up in ProcessExplorer. I wonder how they do it. Too bad we don't have its source code. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 09:01:06 2020 Received: (at 41242) by debbugs.gnu.org; 15 May 2020 13:01:06 +0000 Received: from localhost ([127.0.0.1]:36191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZxa-0003Uu-0d for submit@debbugs.gnu.org; Fri, 15 May 2020 09:01:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZZxY-0003UJ-Bi for 41242@debbugs.gnu.org; Fri, 15 May 2020 09:01:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40759) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZZxQ-0005tw-Og; Fri, 15 May 2020 09:00:56 -0400 Received: from [176.228.60.248] (port=3897 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZZxM-0004Kd-IQ; Fri, 15 May 2020 09:00:53 -0400 Date: Fri, 15 May 2020 16:00:40 +0300 Message-Id: <83o8qp1hfr.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Fri, 15 May 2020 09:33:32 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Fri, 15 May 2020 09:33:32 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > Does that reflect renaming _after_ the library was loaded? > > I get that idea from the documentation. I haven't actually tested it myself. It should be easy to write a program to test this. > The ProcessExplorer utility can show the name of the loaded DLLs > of a process. If I rename one the changed name will show up in ProcessExplorer. > I wonder how they do it. They use methods that are generally unacceptable in general-purpose applications, including injecting code into other processes, using undocumented features and APIs, etc. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 15:44:22 2020 Received: (at 41242) by debbugs.gnu.org; 15 May 2020 19:44:22 +0000 Received: from localhost ([127.0.0.1]:38809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZgFq-0007ev-Dc for submit@debbugs.gnu.org; Fri, 15 May 2020 15:44:22 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:33583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZgFp-0007ej-Hy for 41242@debbugs.gnu.org; Fri, 15 May 2020 15:44:21 -0400 Received: by mail-ot1-f54.google.com with SMTP id v17so2886920ote.0 for <41242@debbugs.gnu.org>; Fri, 15 May 2020 12:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9+JTtNCB1yqbSoWkeRclGjG04pIUEbiMPXjA85Fbhdg=; b=uNNRy3pKVWhurUJZbXu1hyGz4pGkCh61KX1xhFDIB3rkf6X6zT7OKUtRSTrbpuEXcB 0eTfaU3SxC0A+iZmlacsCeIsowuHwOltT32qYJ39fhBtx79WHUVV3SuobFLWXnQ3SQ/B 2dwlnU3qpb3KAWind8SdtjcqXGetaZAOyKkhU1GOLaDaLyETHQCLPfZIfI1soMN1JV7W j/MN1791ZpwpDPbbAflfjog/g5gLpB4TcwWq3dsx9YbU5Ab9cUOw0FSYaBlOYzhgDMTe X8ZaM0bOzEgXqViFi8viKxazkWaidE5Ed0rS/4DaMlaMGIqBd4OK9qKHz17nSjOyD5/L 8yEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9+JTtNCB1yqbSoWkeRclGjG04pIUEbiMPXjA85Fbhdg=; b=Zxlo19y3sT0KWms54b0Poi/pz9vLe8GLyLaM9pk5z++55MtzF0xKom/U2WbHlWac+5 4UTWaz9yWUA5Yiz84hltd4j9BeDxzOURcFfUbnajy+jhraPSyRosxH30z4IHwIMjFRcj wljgPFvA3PpXAo5C1fba69CRkTq/D/35T98yJoRoBQa8a8thXsxNpNFin6WEous3VMGs 9KjEIlxJcKUxXyiZZZhJfJZmItXbJRsYSEjIv8iHJ/BTNz7rusA95uAF/8o5O83n10Yt oBXTu3pZ8wzYQlRjqjon4AGaIClhbRRRKfJh97DXBmuqrSL+Drvwldn4FrxxOVqMZxIx vhRg== X-Gm-Message-State: AOAM533L8vgpFqLwcLcgN0ecO2cPAMhn45EN0x2JDOamNrJXO9MRrdmx ZJHi6Reo28gi7QuiYwXW1H9Y0o8ZNzhGUBjoXXc= X-Google-Smtp-Source: ABdhPJz/p6VoOcMaVI8zG/TMZPe2Eh8AnvtkTalps2akAyI7X52IPOsDrR/47IEQNVpIQBDYU0oTvsMv+KT487mHZpw= X-Received: by 2002:a9d:191:: with SMTP id e17mr3317915ote.193.1589571855621; Fri, 15 May 2020 12:44:15 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> In-Reply-To: <83o8qp1hfr.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Fri, 15 May 2020 16:44:04 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) To summarize: The best idea seems to be to rename the .eln file when removing the package or recompiling. We need to reach a consensus on where to put the old .eln file, though. There are two options: - Put it in the same folder as the original .eln file. This means that `package-delete` will not be able to delete the directory. Additionally, it will be tricky to handle left over files from an instance of Emacs that crashes. - Another option is to move them to `package-user-dir`. This option means that `package-delete` will be able to delete the directory. What option do you prefer? The implementation I have in mind is roughly like this: - `package-delete` iterates over the .eln files in the package directory. It tries to delete it, if it fails it is moved to somewhere (see point above). - When Emacs GCs a native compilation unit it should check if it has been renamed (need to check if GetModuleFileNameA is fit for this). If it has, it tries to delete it. If it fails, then some other Emacs instance must be using it. - The last step before calling exit() should FreeLibrary() all remaining .eln files and run the equivalent of `rm $package_user_dir/*.eln.old`. I think this would work and should be simple to implement. If I get your OK I'll try to do it this weekend. Nicolas From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 02:22:31 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 06:22:31 +0000 Received: from localhost ([127.0.0.1]:39605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZqDP-00007o-Bx for submit@debbugs.gnu.org; Sat, 16 May 2020 02:22:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZqDN-00007W-3u for 41242@debbugs.gnu.org; Sat, 16 May 2020 02:22:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59930) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZqDG-0005Kg-Kb; Sat, 16 May 2020 02:22:22 -0400 Received: from [176.228.60.248] (port=3783 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZqDG-0007T7-11; Sat, 16 May 2020 02:22:22 -0400 Date: Sat, 16 May 2020 09:22:11 +0300 Message-Id: <837dxcv1po.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Fri, 15 May 2020 16:44:04 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Fri, 15 May 2020 16:44:04 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > To summarize: > > The best idea seems to be to rename the .eln file when removing the package or > recompiling. We need to reach a consensus on where to put the old .eln file, > though. > > There are two options: > > - Put it in the same folder as the original .eln file. This means that > `package-delete` will not be able to delete the directory. Additionally, it > will be tricky to handle left over files from an instance of Emacs that > crashes. > > - Another option is to move them to `package-user-dir`. This option means that > `package-delete` will be able to delete the directory. > > What option do you prefer? I'm not sure I understand why we are talking only about package.el. Wouldn't the same problem happen if the user recompiles a .el file for which a .eln file already exists and is loaded into the session? And similarly when Emacs is being built and all the *.el files are being compiled or recompiled, sometimes by several Emacs processes running in parallel via "make -jN"? I think the solution should handle all of these use cases, not just that of package.el upgrading a package. Do you agree? > - `package-delete` iterates over the .eln files in the package directory. It > tries to delete it, if it fails it is moved to somewhere (see point above). > > - When Emacs GCs a native compilation unit it should check if it has been > renamed (need to check if GetModuleFileNameA is fit for this). If it has, it > tries to delete it. If it fails, then some other Emacs instance must be using > it. > > - The last step before calling exit() should FreeLibrary() all remaining .eln > files and run the equivalent of `rm $package_user_dir/*.eln.old`. Sounds OK to me, I don't think we came up with anything better during the discussion till now. From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 03:12:51 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 07:12:51 +0000 Received: from localhost ([127.0.0.1]:39652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZr06-0001KX-UU for submit@debbugs.gnu.org; Sat, 16 May 2020 03:12:51 -0400 Received: from mx.sdf.org ([205.166.94.20]:53207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZr05-0001KP-8N for 41242@debbugs.gnu.org; Sat, 16 May 2020 03:12:50 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04G7CmI8021637 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 16 May 2020 07:12:48 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04G7ClAK009487; Sat, 16 May 2020 07:12:47 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> Date: Sat, 16 May 2020 07:12:47 +0000 In-Reply-To: <837dxcv1po.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 May 2020 09:22:11 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: >> From: Nicolas B=C3=A9rtolo >> Date: Fri, 15 May 2020 16:44:04 -0300 >> Cc: Andrea Corallo , 41242@debbugs.gnu.org >>=20 >> To summarize: >>=20 >> The best idea seems to be to rename the .eln file when removing the pack= age or >> recompiling. We need to reach a consensus on where to put the old .eln f= ile, >> though. >>=20 >> There are two options: >>=20 >> - Put it in the same folder as the original .eln file. This means that >> `package-delete` will not be able to delete the directory. Additionall= y, it >> will be tricky to handle left over files from an instance of Emacs that >> crashes. >>=20 >> - Another option is to move them to `package-user-dir`. This option mean= s that >> `package-delete` will be able to delete the directory. >>=20 >> What option do you prefer? > > I'm not sure I understand why we are talking only about package.el. > Wouldn't the same problem happen if the user recompiles a .el file for > which a .eln file already exists and is loaded into the session? IIUC the complication of package.el that makes it different from the general cases you have described is that the eln-... sub-directory has to be removed to be able to clean-up entirely the package. > And > similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN"? > > I think the solution should handle all of these use cases, not just > that of package.el upgrading a package. Do you agree? > >> - `package-delete` iterates over the .eln files in the package directory= . It >> tries to delete it, if it fails it is moved to somewhere (see point ab= ove). >>=20 >> - When Emacs GCs a native compilation unit it should check if it has been >> renamed (need to check if GetModuleFileNameA is fit for this). If it h= as, it >> tries to delete it. If it fails, then some other Emacs instance must b= e using >> it. >>=20 >> - The last step before calling exit() should FreeLibrary() all remaining= .eln >> files and run the equivalent of `rm $package_user_dir/*.eln.old`. > > Sounds OK to me, I don't think we came up with anything better during > the discussion till now. > --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 12:12:40 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 16:12:40 +0000 Received: from localhost ([127.0.0.1]:41554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzQV-0000fS-KH for submit@debbugs.gnu.org; Sat, 16 May 2020 12:12:40 -0400 Received: from mail-oo1-f48.google.com ([209.85.161.48]:44886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzQT-0000fF-T3 for 41242@debbugs.gnu.org; Sat, 16 May 2020 12:12:38 -0400 Received: by mail-oo1-f48.google.com with SMTP id p67so1125518ooa.11 for <41242@debbugs.gnu.org>; Sat, 16 May 2020 09:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ixCBxUESAjUOcbwKZl+wX2S7R6xrzFNHIVAyFSlZIAI=; b=ePJqmBEkpoWoNZgE0mPZKu54ks2Xyy0VIlbWZUnJDZRjKhlmGhd/NkYtMWznsTqZRG Jo5SnSZ0Cc9yiePdSjZkp0botN+/7Zu3a4OBx676h7UCsy+4+0V5qinrgQSQNlmPr/lM y+HYX5T+J+4mIIGWQXBOwEgx2U+czY6TcDR/9mhd2izNfpdlgbs3o16ae9GC6qeY5skX BKLKuQVGjLTcGo0oZ7x9yuP/RTGa1MZA0lUkvfcsM+HnTBvuYZ/H/Y8JL8EThMaa6GAD J55wtpeOpdjhneaWeRDtWdyz4ng8A/OKzI0T5SEFWUiZGZd4OqdFCLFBSwMvDiaoW5Z9 2umQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ixCBxUESAjUOcbwKZl+wX2S7R6xrzFNHIVAyFSlZIAI=; b=fn+emfJLXx7cZ9JnxuyX62CKkovjKOs3dOL7Rv+x6X2i6x/19/IE/nuCWdU/I4/sRb ogH46cJs4EPRbUBRsGki1/HqEADW+wcPljQACtk10nqEVbej9mafqmpqPlBwyRjSV8Gn A4ATcjIL59PfuzL3Qwvz4R1WDvnd94QLDmsu1GvIjcDpgouVvCZIESyloj0YAHDuNT+R P8X4e6BghBnuzjLATMVvPpIeh5jqBEjHui+vzhXxnwLlcBmCunLVBA69DIMfA98RwLNg BmxHMB2l8mrLrDpzjEbSLcB+psh78o6cALxmLXx/oW4DUAAq5ULg8eWMZUWBm0MeysPl kuBQ== X-Gm-Message-State: AOAM532UPDZ/uexgbi+XJZpXwUSsa5wncVmkQycorlhDnxptXSuR7HUY YwTVHKJzdc6FNqBACv8jeYJlAHkYpLu/GDKWWc/DXLfRHxbKkA== X-Google-Smtp-Source: ABdhPJwoMo9WLB2izJuRoEJNqJ3zV16x656SjhMShnMaqj6uSZpleJ1qYrlglsv9Etx94IaUl6jmZiBYVDlc6uRjcQo= X-Received: by 2002:a4a:b389:: with SMTP id p9mr6808189ooo.84.1589645552131; Sat, 16 May 2020 09:12:32 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> In-Reply-To: <837dxcv1po.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 16 May 2020 13:12:20 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000074214705a5c632c0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --00000000000074214705a5c632c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand why we are talking only about package.el. > Wouldn't the same problem happen if the user recompiles a .el file for > which a .eln file already exists and is loaded into the session? True, right now the .eln would not be removed. Not even in Posix. Therefore it will continue to be loaded unless `load-prefer-newer` is true. > And > similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN" Help me understand. Are you referring to the case where a developer changes an .el file for which an .eln file (now outdated) already exists? I think fixing the case above will fix this one. El s=C3=A1b., 16 may. 2020 a las 3:22, Eli Zaretskii () escri= bi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Fri, 15 May 2020 16:44:04 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > To summarize: > > > > The best idea seems to be to rename the .eln file when removing the > package or > > recompiling. We need to reach a consensus on where to put the old .eln > file, > > though. > > > > There are two options: > > > > - Put it in the same folder as the original .eln file. This means that > > `package-delete` will not be able to delete the directory. > Additionally, it > > will be tricky to handle left over files from an instance of Emacs th= at > > crashes. > > > > - Another option is to move them to `package-user-dir`. This option > means that > > `package-delete` will be able to delete the directory. > > > > What option do you prefer? > > I'm not sure I understand why we are talking only about package.el. > Wouldn't the same problem happen if the user recompiles a .el file for > which a .eln file already exists and is loaded into the session? And > similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN"? > > I think the solution should handle all of these use cases, not just > that of package.el upgrading a package. Do you agree? > > > - `package-delete` iterates over the .eln files in the package > directory. It > > tries to delete it, if it fails it is moved to somewhere (see point > above). > > > > - When Emacs GCs a native compilation unit it should check if it has be= en > > renamed (need to check if GetModuleFileNameA is fit for this). If it > has, it > > tries to delete it. If it fails, then some other Emacs instance must > be using > > it. > > > > - The last step before calling exit() should FreeLibrary() all remainin= g > .eln > > files and run the equivalent of `rm $package_user_dir/*.eln.old`. > > Sounds OK to me, I don't think we came up with anything better during > the discussion till now. > --00000000000074214705a5c632c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'm not sure I understand why we are talking only= about package.el.
> Wouldn't the same problem happen if the user= recompiles a .el file for
> which a .eln file already exists and is loaded into the session?=C2=A0=

True, right now the .eln would not be remove= d. Not even in Posix.
Therefore it will continue to be loaded unl= ess `load-prefer-newer` is true.

>=20 And
> similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN"

Help me = understand. Are you referring to the case where a developer changes
an .el file for which an .eln file (now outdated) already exists? I thin= k fixing the
case above will fix this one.


El s=C3=A1b., 16 may. 2020 a las 3:22, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
> From: Nicolas B=C3=A9rtolo <= nicolasbertol= o@gmail.com>
> Date: Fri, 15 May 2020 16:44:04 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> To summarize:
>
> The best idea seems to be to rename the .eln file when removing the pa= ckage or
> recompiling. We need to reach a consensus on where to put the old .eln= file,
> though.
>
> There are two options:
>
> - Put it in the same folder as the original .eln file. This means that=
>=C2=A0 =C2=A0`package-delete` will not be able to delete the directory.= Additionally, it
>=C2=A0 =C2=A0will be tricky to handle left over files from an instance = of Emacs that
>=C2=A0 =C2=A0crashes.
>
> - Another option is to move them to `package-user-dir`. This option me= ans that
>=C2=A0 =C2=A0`package-delete` will be able to delete the directory.
>
> What option do you prefer?

I'm not sure I understand why we are talking only about package.el.
Wouldn't the same problem happen if the user recompiles a .el file for<= br> which a .eln file already exists and is loaded into the session?=C2=A0 And<= br> similarly when Emacs is being built and all the *.el files are being
compiled or recompiled, sometimes by several Emacs processes running
in parallel via "make -jN"?

I think the solution should handle all of these use cases, not just
that of package.el upgrading a package.=C2=A0 Do you agree?

> - `package-delete` iterates over the .eln files in the package directo= ry. It
>=C2=A0 =C2=A0tries to delete it, if it fails it is moved to somewhere (= see point above).
>
> - When Emacs GCs a native compilation unit it should check if it has b= een
>=C2=A0 =C2=A0renamed (need to check if GetModuleFileNameA is fit for th= is). If it has, it
>=C2=A0 =C2=A0tries to delete it. If it fails, then some other Emacs ins= tance must be using
>=C2=A0 =C2=A0it.
>
> - The last step before calling exit() should FreeLibrary() all remaini= ng .eln
>=C2=A0 =C2=A0files and run the equivalent of `rm $package_user_dir/*.el= n.old`.

Sounds OK to me, I don't think we came up with anything better during the discussion till now.
--00000000000074214705a5c632c0-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 12:19:39 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 16:19:39 +0000 Received: from localhost ([127.0.0.1]:41564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzXG-0000qQ-RF for submit@debbugs.gnu.org; Sat, 16 May 2020 12:19:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzXE-0000qC-Kp for 41242@debbugs.gnu.org; Sat, 16 May 2020 12:19:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44169) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZzX8-0002GQ-Oy; Sat, 16 May 2020 12:19:30 -0400 Received: from [176.228.60.248] (port=1168 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZzX8-0001Ug-5I; Sat, 16 May 2020 12:19:30 -0400 Date: Sat, 16 May 2020 19:19:19 +0300 Message-Id: <83imgvdf94.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 16 May 2020 13:12:20 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 16 May 2020 13:12:20 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > I'm not sure I understand why we are talking only about package.el. > > Wouldn't the same problem happen if the user recompiles a .el file for > > which a .eln file already exists and is loaded into the session? > > True, right now the .eln would not be removed. Not even in Posix. No, on Posix systems we can delete the file, and it will be actually deleted when its last handle is closed. I believe this works with shared libraries as well. > > And > > similarly when Emacs is being built and all the *.el files are being > > compiled or recompiled, sometimes by several Emacs processes running > > in parallel via "make -jN" > > Help me understand. Are you referring to the case where a developer changes > an .el file for which an .eln file (now outdated) already exists? No, I mean building Emacs with "make -j10 bootstrap". > I think fixing the case above will fix this one. It's the same problem, yes. Just a slightly different use case, which could therefore have different probabilities for some aspects. For example, the probability of the same .el file being recompiled from two separate sessions is relatively small, except when you consider the "make -jN" use case. From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 12:32:01 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 16:32:01 +0000 Received: from localhost ([127.0.0.1]:41570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzjE-00018v-V2 for submit@debbugs.gnu.org; Sat, 16 May 2020 12:32:01 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:45970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzjC-00018i-UX for 41242@debbugs.gnu.org; Sat, 16 May 2020 12:31:59 -0400 Received: by mail-ot1-f50.google.com with SMTP id c3so4474642otr.12 for <41242@debbugs.gnu.org>; Sat, 16 May 2020 09:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E1paJ690TaTZihV6dqvH4Yb6V2xdIg+3sGvgc6mZWT0=; b=Nwo5dAg4jsfTwMLOm9F1g0WUHStEVU2+KiZvkl1ddHJAr2alWeKdBSIXAChgBemtz3 10ZftJ5RyBUsm1lBWB2F5q/M73hEWVT7nudHPI3yJej6MFa5hOa7vudKVOtPrlXEGrYH qrGX5UJ60cEm7orZsTtHFmnJ8d2PNaxTKXyjLnU0788N/GsaO6M2KPWz87DDcE+qiNPr GqCB/yKQU3aVgsF7yGQvx5yoP9chQxGhGRvOFQDh/tVoI6wwsj71ibjbtoGpNQh4e1bC fB+Q6iTKoVAjFfXMuIrbxigdc46euekGNxTz9szewNYVrgF/Mw6za4iqYfL3ZKrAiChD PDnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E1paJ690TaTZihV6dqvH4Yb6V2xdIg+3sGvgc6mZWT0=; b=qpH3YJjTM5zK0JxLsmHJFxUzFQNEU8t2lzVCDeJlCKmRQ1YCEj1fJjVDz51jTKhDdp zYiD15/rB2J9LIeJJ45xpCY0ASAQ9UNeql1CoCgo4XOO0Jng28uUACB+E030v/+Z90fF 1hZzcXBAjzduMgL+n6d3hV93Y1g7tlJtBUdS3SrVRPd44fwKjp24okdLnIEW3KrseToW 7LdqwBVoZ6RX5o2CvsiCAbkDUR7nW8TqVL540VjMqCYUIcsfUm+9xgwL0+e+nK3L5VUV eFsO7IGnhmaIz5lAVlN4S9ppkWDwvtRjFiP7XiRHRm/LTWkby7P47z1xqLviCcsIbpGu XB/Q== X-Gm-Message-State: AOAM532nbMdrvqshpas55KOitjI+BcrVqUf0VYvtP6l8bxDfZl7tR/UJ zg91ah2yGDHGhXvasc5TLwdr15oAQwTCtHDWYpg= X-Google-Smtp-Source: ABdhPJwPpi4t43eMgaNBoRdrSvi/ry1Rl9hcH6GUgR2YZnrXJIA/bomI8QbWwsVad21LvfbeUMi6x2JsC7Q5TJzNZwg= X-Received: by 2002:a9d:3988:: with SMTP id y8mr6013655otb.352.1589646713309; Sat, 16 May 2020 09:31:53 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> In-Reply-To: <83imgvdf94.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 16 May 2020 13:31:41 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000aa4b9b05a5c677d3" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --000000000000aa4b9b05a5c677d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > No, on Posix systems we can delete the file, and it will be actually > deleted when its last handle is closed. I believe this works with > shared libraries as well. Do we actually do it? I don't think so. I don't even know where exactly that check should be. Maybe `eval-buffer`? > It's the same problem, yes. Just a slightly different use case, which > could therefore have different probabilities for some aspects. For > example, the probability of the same .el file being recompiled from > two separate sessions is relatively small, except when you consider > the "make -jN" use case. The probability of two Emacs recompiling the same file in the "make -jN" case is 0. That is because the build system tells each Emacs to compile one and only one file that is passed as a parameter. See #41329 for a bug related to this. The case of two Emacs sessions recompiling the same file at the same time i= s actually a problem. We could implement the following algorithm: - Have libgccjit write the .eln to a temporary name in the destination folder. - While "foo.eln" exists: - Rename it to "foo.eln.oldN". - Move the new .eln file to "foo.eln" Nicolas El s=C3=A1b., 16 may. 2020 a las 13:19, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 16 May 2020 13:12:20 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > I'm not sure I understand why we are talking only about package.el. > > > Wouldn't the same problem happen if the user recompiles a .el file fo= r > > > which a .eln file already exists and is loaded into the session? > > > > True, right now the .eln would not be removed. Not even in Posix. > > No, on Posix systems we can delete the file, and it will be actually > deleted when its last handle is closed. I believe this works with > shared libraries as well. > > > > And > > > similarly when Emacs is being built and all the *.el files are being > > > compiled or recompiled, sometimes by several Emacs processes running > > > in parallel via "make -jN" > > > > Help me understand. Are you referring to the case where a developer > changes > > an .el file for which an .eln file (now outdated) already exists? > > No, I mean building Emacs with "make -j10 bootstrap". > > > I think fixing the case above will fix this one. > > It's the same problem, yes. Just a slightly different use case, which > could therefore have different probabilities for some aspects. For > example, the probability of the same .el file being recompiled from > two separate sessions is relatively small, except when you consider > the "make -jN" use case. > --000000000000aa4b9b05a5c677d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=20 No, on Posix systems we can delete the file, and it will be actually
>= ; deleted when its last handle is closed.=C2=A0 I believe this works with
> shared libraries as well.

Do we actually do it? I don't think so. I don't ev= en know where exactly
that check should be. Maybe `eval-buffer`?<= br>

> It's the same problem, yes.=C2=A0 Jus= t a slightly different use case, which
> could therefore have differe= nt probabilities for some aspects.=C2=A0 For
> example, the probabili= ty of the same .el file being recompiled from
> two separate sessions= is relatively small, except when you consider
> the "make -jN&q= uot; use case.

The probability of two Emacs recompiling the same fil= e in the "make -jN" case is
0. That is because the build syste= m tells each Emacs to compile one and only one
file that is passed as a = parameter. See #41329 for a bug related to this.

The case of two Ema= cs sessions recompiling the same file at the same time is
actually a pro= blem.

We could implement the following algorithm:

- Have libg= ccjit write the .eln to a temporary name in the destination folder.

= - While "foo.eln" exists:
=C2=A0 - Rename it to "foo.eln.= oldN".
=C2=A0 - Move the new .eln file to "foo.eln"
Nicolas


= El s=C3=A1b., 16 may. 2020 a las 13:19, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
> From: Nicolas B=C3=A9rtolo <nicolasbertolo@= gmail.com>
> Date: Sat, 16 May 2020 13:12:20 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > I'm not sure I understand why we are talking only about packa= ge.el.
> > Wouldn't the same problem happen if the user recompiles a .el= file for
> > which a .eln file already exists and is loaded into the session?= =C2=A0
>
> True, right now the .eln would not be removed. Not even in Posix.

No, on Posix systems we can delete the file, and it will be actually
deleted when its last handle is closed.=C2=A0 I believe this works with
shared libraries as well.

> > And
> > similarly when Emacs is being built and all the *.el files are be= ing
> > compiled or recompiled, sometimes by several Emacs processes runn= ing
> > in parallel via "make -jN"
>
> Help me understand. Are you referring to the case where a developer ch= anges
> an .el file for which an .eln file (now outdated) already exists?

No, I mean building Emacs with "make -j10 bootstrap".

> I think fixing the case above will fix this one.

It's the same problem, yes.=C2=A0 Just a slightly different use case, w= hich
could therefore have different probabilities for some aspects.=C2=A0 For example, the probability of the same .el file being recompiled from
two separate sessions is relatively small, except when you consider
the "make -jN" use case.
--000000000000aa4b9b05a5c677d3-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 12:42:53 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 16:42:53 +0000 Received: from localhost ([127.0.0.1]:41592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZztd-0001Q5-9o for submit@debbugs.gnu.org; Sat, 16 May 2020 12:42:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZztb-0001Po-UI for 41242@debbugs.gnu.org; Sat, 16 May 2020 12:42:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44444) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZztW-0006Ef-Ht; Sat, 16 May 2020 12:42:38 -0400 Received: from [176.228.60.248] (port=2810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZztW-00057d-3Z; Sat, 16 May 2020 12:42:38 -0400 Date: Sat, 16 May 2020 19:42:27 +0300 Message-Id: <83eerjde6k.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 16 May 2020 13:31:41 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 16 May 2020 13:31:41 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > No, on Posix systems we can delete the file, and it will be actually > > deleted when its last handle is closed. I believe this works with > > shared libraries as well. > > Do we actually do it? I don't think so. I don't even know where exactly > that check should be. Maybe `eval-buffer`? I'm not sure I understand what check did you have in mind. > > It's the same problem, yes. Just a slightly different use case, which > > could therefore have different probabilities for some aspects. For > > example, the probability of the same .el file being recompiled from > > two separate sessions is relatively small, except when you consider > > the "make -jN" use case. > > The probability of two Emacs recompiling the same file in the "make -jN" case is > 0. Sorry, I meant the probability of one session compiling a file while another uses it. > The case of two Emacs sessions recompiling the same file at the same time is > actually a problem. > > We could implement the following algorithm: > > - Have libgccjit write the .eln to a temporary name in the destination folder. > > - While "foo.eln" exists: > - Rename it to "foo.eln.oldN". > - Move the new .eln file to "foo.eln" Something like that, yes. From debbugs-submit-bounces@debbugs.gnu.org Sat May 16 13:10:13 2020 Received: (at 41242) by debbugs.gnu.org; 16 May 2020 17:10:13 +0000 Received: from localhost ([127.0.0.1]:41642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja0KC-0002YD-Te for submit@debbugs.gnu.org; Sat, 16 May 2020 13:10:13 -0400 Received: from mail-ot1-f53.google.com ([209.85.210.53]:44316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja0KB-0002Xz-R7 for 41242@debbugs.gnu.org; Sat, 16 May 2020 13:10:12 -0400 Received: by mail-ot1-f53.google.com with SMTP id f18so442905otq.11 for <41242@debbugs.gnu.org>; Sat, 16 May 2020 10:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yO0SIUU0YKTzjl1zlCQWsySzA0Gh6hvn9zkDNI+h718=; b=gUZ8sGarEbMtAuoH9S36R8/n1GnW++tk+rRKHtfe/vBMDrdfWtzpQMmB1WuFfIgRsn 0K3j52j9RogLgBX04QsHylYkDqHh3XOe5QynuxmaxFiiXloNImbVDpsLmg+YMSG46IE0 QKF8HSyXbhSKu8pi4KMFoTuiBKI1eETfXMoj6ha8AU3rVHm02MIV5MNvvRN+hzhV+jTY y0rXfCegtE9KQiSJoz554E8p5TphvDwAtd8P/pgoKT/bEDQTHGyt+9UgHrOe7+gD1wrI 5WcMA+3+8XrSx3m8I50RopAbaYU87Pdz4zUtujH8lC/2DiioIIS5H992mMYWCXwAPwJa X7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yO0SIUU0YKTzjl1zlCQWsySzA0Gh6hvn9zkDNI+h718=; b=rJ3Pt9TVVv1RWMD7BKR3HGoMAXXmKwObcwvz5rRVdIj2Js9B968KoARaAd/I1p4rnt TB1rpIRAI8HCWgfsaT1wmLtqY8Kt9jT+ZxhmfRdr/zayUSE80HLUTUwq8GpG8/jwxI/T SWM4OVuScwkEYUkYTEcJ1XFjrzH9IdRuwAGv5DVGRlVDtbqinc5ifxOkmb0FvKLOecfy PkZgSRePczq6OEeflUtrMUQh1UGqD69vtx4CTuB80vJrUObzK8bT17sL+FZacuhUtTo3 /A6EL6nsawcuJ744NbViTgvNW4zQ88AzWACLz/SvtrfGK3cahdpXeULapffm7er6lk8u XY/Q== X-Gm-Message-State: AOAM530F70AQWJRXG9bMA0HJQ5DgWUDk+fdW6RBlGE/MwtNvU4vEzxLi 62+sxYp6xwn+7c6sPMBz0ewuz7dGcVcGwV9l3RU= X-Google-Smtp-Source: ABdhPJyYLvM08QsAysalUIWcKYd2jLv7doYKbAipHcSWyna6xL1aZxxGYiOuOBYlsSuqIzxvSHe1Eog00iGc7Wunjgc= X-Received: by 2002:a9d:3988:: with SMTP id y8mr6102802otb.352.1589649006228; Sat, 16 May 2020 10:10:06 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> In-Reply-To: <83eerjde6k.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 16 May 2020 14:09:54 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000055792005a5c700fb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --00000000000055792005a5c700fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand what check did you have in mind. I misunderstood your first message. I thought you were talking about deleting the .eln file when it no longer is up to date after the .el file changes. If we want that we will have to add it to `auto-compile.el`. El s=C3=A1b., 16 may. 2020 a las 13:42, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 16 May 2020 13:31:41 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > No, on Posix systems we can delete the file, and it will be actually > > > deleted when its last handle is closed. I believe this works with > > > shared libraries as well. > > > > Do we actually do it? I don't think so. I don't even know where exactly > > that check should be. Maybe `eval-buffer`? > > I'm not sure I understand what check did you have in mind. > > > > It's the same problem, yes. Just a slightly different use case, whic= h > > > could therefore have different probabilities for some aspects. For > > > example, the probability of the same .el file being recompiled from > > > two separate sessions is relatively small, except when you consider > > > the "make -jN" use case. > > > > The probability of two Emacs recompiling the same file in the "make -jN= " > case is > > 0. > > Sorry, I meant the probability of one session compiling a file while > another uses it. > > > The case of two Emacs sessions recompiling the same file at the same > time is > > actually a problem. > > > > We could implement the following algorithm: > > > > - Have libgccjit write the .eln to a temporary name in the destination > folder. > > > > - While "foo.eln" exists: > > - Rename it to "foo.eln.oldN". > > - Move the new .eln file to "foo.eln" > > Something like that, yes. > --00000000000055792005a5c700fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'm not sure I understand what check did you have= in mind.

I misunderstood your first message. I thought you were tal= king about deleting
the .eln file when it no longer is up to date after = the .el file changes.

If we want that we will have to add it to `aut= o-compile.el`.

El s=C3=A1b., 16 may. 2020 a las 13:42, Eli Zaretskii (&l= t;eliz@gnu.org>) escribi=C3=B3:
<= /div>
> From: Nicolas B= =C3=A9rtolo <nicolasbertolo@gmail.com>
> Date: Sat, 16 May 2020 13:31:41 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > No, on Posix systems we can delete the file, and it will be actua= lly
> > deleted when its last handle is closed.=C2=A0 I believe this work= s with
> > shared libraries as well.
>
> Do we actually do it? I don't think so. I don't even know wher= e exactly
> that check should be. Maybe `eval-buffer`?

I'm not sure I understand what check did you have in mind.

> > It's the same problem, yes.=C2=A0 Just a slightly different u= se case, which
> > could therefore have different probabilities for some aspects.=C2= =A0 For
> > example, the probability of the same .el file being recompiled fr= om
> > two separate sessions is relatively small, except when you consid= er
> > the "make -jN" use case.
>
> The probability of two Emacs recompiling the same file in the "ma= ke -jN" case is
> 0.

Sorry, I meant the probability of one session compiling a file while
another uses it.

> The case of two Emacs sessions recompiling the same file at the same t= ime is
> actually a problem.
>
> We could implement the following algorithm:
>
> - Have libgccjit write the .eln to a temporary name in the destination= folder.
>
> - While "foo.eln" exists:
>=C2=A0 =C2=A0- Rename it to "foo.eln.oldN".
>=C2=A0 =C2=A0- Move the new .eln file to "foo.eln"

Something like that, yes.
--00000000000055792005a5c700fb-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 19 15:23:26 2020 Received: (at 41242) by debbugs.gnu.org; 19 May 2020 19:23:26 +0000 Received: from localhost ([127.0.0.1]:51141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jb7pm-0005mV-G8 for submit@debbugs.gnu.org; Tue, 19 May 2020 15:23:26 -0400 Received: from mail-oo1-f45.google.com ([209.85.161.45]:33617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jb7pl-0005mJ-Ca for 41242@debbugs.gnu.org; Tue, 19 May 2020 15:23:25 -0400 Received: by mail-oo1-f45.google.com with SMTP id q6so214502oot.0 for <41242@debbugs.gnu.org>; Tue, 19 May 2020 12:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fyAVXXh68xvBUCDotGRw+Xh+qI6ioJRoUfUmZl+PRv4=; b=dqbC0DmHlUMQrrGaDQQ5YH5RnXHcdn7mebPilbAkjgAMPB0oHCnsiewYqPWiwGnDS8 IK5sgk4hBq+I9sKO/bk3K30mbtPmZSyJ+ITa3auOKTFr1ZIyIIoGMfNy8gkju7S4UaZN gb93pfMLlhoGiUjidkEFYu8WO255Fw/GGXjsDg7DN1+Y+x/S4Klg02KbLQWoEPL1uHLa 2+ARlQnmcy6Xggs7Bw6TPQsvDGl0TMMK//OjpEpBo5JWEhCujXQS+mXj0OCfYCC5jxeZ 17Kr+4GICoI+MbT06yJU06wWNyUirsu+QsTN8FuyfeTu64Qzy5lv+FpIhIs1QpOl31YY gLJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fyAVXXh68xvBUCDotGRw+Xh+qI6ioJRoUfUmZl+PRv4=; b=I1SJ5Mwqsnc04NGB6QzTGZfiLX4VSc+aNGoqYvI6U1hYuvxoEM8sIUa6weA5WUsJ2l Y9apx1XiLMJIq9khpyJvQtMl8KBq/vIkbb1dbu0mXv1jJnTX+2b/DYr6j3eTYTbofGqK D1WqUP3PLRNB00vscDm82wR1gWak7fHhRRQ3lOqOrJoH1mlE+jBOidD8EN2g8G8GM5af LpBBGW7C/53SA7nPSnvbNKslbGuivc65OeluRjnYipLsKoJ2QP6t2n4fEr217Lj8MoWS rIK9jvwKTvPojvMuHhNS6ziC97wwq8go0qcx5/bGWIqGgcjX/YpAvLKu6Ay6NP96K9qV 05Og== X-Gm-Message-State: AOAM533uvL+KZrDydTpZ2QD1AYhGlAka0qNoO1Mb+ETiwS/XTEjI5eEP VpwlIzZ/Fk2CzsoVqquUU/YZL6cvFuCB8ftEPU+z2Nuz X-Google-Smtp-Source: ABdhPJy7sT2+AXWtlodw9nQhO/tzksE0EJ3CBwXe/Gw7WaD/8sPo0maL5miVNo6WYB2qH5u8Y7CfkZcmwheYZyFQRGs= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr587523oon.22.1589916199680; Tue, 19 May 2020 12:23:19 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> In-Reply-To: <83eerjde6k.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Tue, 19 May 2020 16:23:06 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000004e7dbe05a60536de" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --0000000000004e7dbe05a60536de Content-Type: multipart/alternative; boundary="0000000000004e7dbb05a60536dc" --0000000000004e7dbb05a60536dc Content-Type: text/plain; charset="UTF-8" I have written the attached patch to handle the deletion of native compilation units still in use. I have tested that it works well. --0000000000004e7dbb05a60536dc Content-Type: text/html; charset="UTF-8"
I have written the attached patch to handle the deletion
of native compilation units still in use. I have tested that it works well.
--0000000000004e7dbb05a60536dc-- --0000000000004e7dbe05a60536de Content-Type: application/octet-stream; name="0001-Improve-handling-of-native-compilation-units-still-i.patch" Content-Disposition: attachment; filename="0001-Improve-handling-of-native-compilation-units-still-i.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kaeaywxm0 RnJvbSBhZGZjY2EzOGY3NmFmMzc5NmZlOGNjNTk2ODRlZDVlMjQ5ODdmMjRjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogVHVlLCAxOSBNYXkgMjAyMCAxNTo1 NzozMSAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIEltcHJvdmUgaGFuZGxpbmcgb2YgbmF0aXZlIGNv bXBpbGF0aW9uIHVuaXRzIHN0aWxsIGluIHVzZSBpbgogV2luZG93cwoKV2hlbiBjbG9zaW5nIGVt YWNzIHdpbGwgaW5zcGVjdCBhbGwgZGlyZWN0b3JpZXMgZnJvbSB3aGljaCBpdCBsb2FkZWQKbmF0 aXZlIGNvbXBpbGF0aW9uIHVuaXRzLiBJZiBpdCBmaW5kcyBhICIuZWxuLm9sZCIgZmlsZSBpdCB3 aWxsIHRyeSB0bwpkZWxldGUgaXQsIGlmIGl0IGZhaWxzIHRoYXQgbWVhbnMgdGhhdCBhbm90aGVy IEVtYWNzIGluc3RhbmNlIGlzIHVzaW5nIGl0LgoKV2hlbiBjb21waWxpbmcgYSBmaWxlIHdlIHJl bmFtZSB0aGUgZmlsZSB0aGF0IHdhcyBpbiB0aGUgb3V0cHV0IHBhdGgKaW4gY2FzZSBpdCBoYXMg YmVlbiBsb2FkZWQgaW50byBhbm90aGVyIEVtYWNzIGluc3RhbmNlLgoKV2hlbiBkZWxldGluZyBh IHBhY2thZ2Ugd2UgbW92ZSBhbnkgIi5lbG4iIG9yICIuZWxuLm9sZCIgZmlsZXMgaW4gdGhlCnBh Y2thZ2UgZm9sZGVyIHRoYXQgd2UgY2FuJ3QgZGVsZXRlIHRvIGBwYWNrYWdlLXVzZXItZGlyYC4g RW1hY3Mgd2lsbApjaGVjayB0aGF0IGRpcmVjdG9yeSB3aGVuIGNsb3NpbmcgYW5kIGRlbGV0ZSB0 aGVtLgoKKiBsaXNwL2VtYWNzLWxpc3AvY29tcC5lbCAoY29tcC0tcmVwbGFjZS1vdXRwdXQtZmls ZSk6IEZ1bmN0aW9uIGNhbGxlZApmcm9tIEMgY29kZSB0byBmaW5pc2ggdGhlIGNvbXBpbGF0aW9u IHByb2Nlc3MuIEl0IHBlcmZvcm1zIHJlbmFtaW5nIG9mCnRoZSBvbGQgZmlsZSBpZiBuZWNlc3Nh cnkuCiogbGlzcC9lbWFjcy1saXNwL3BhY2thZ2UuZWwgKHBhY2thZ2UtLWRlbGV0ZS1kaXJlY3Rv cnkpOiBGdW5jdGlvbiB0bwpkZWxldGUgYSBwYWNrYWdlIGRpcmVjdG9yeS4gSXQgbW92ZXMgbmF0 aXZlIGNvbXBpbGF0aW9uIHVuaXRzIHRoYXQgaXQKY2FuJ3QgZGVsZXRlIHRvIGBwYWNrYWdlLXVz ZXItZGlyJy4KKiBzcmMvYWxsb2MuYyAoY2xlYW51cF92ZWN0b3IpOiBDYWxsIGRpc3Bvc2VfY29t cF91bml0KCkuCiAgKGdhcmJhZ2VfY29sbGVjdCk6IENhbGwgZmluaXNoX2RlbGF5ZWRfZGlzcG9z YWxfb2ZfY29tcF91bml0cygpLgoqIHNyYy9jb21wLmM6IFJlc3RvcmUgdGhlIHNpZ25hbCBtYXNr IHVzaW5nIHVud2luZC1wcm90ZWN0LiBTdG9yZQpsb2FkZWQgbmF0aXZlIGNvbXBpbGF0aW9uIHVu aXRzIGluIGEgaGFzaCB0YWJsZSBmb3IgZGlzcG9zYWwgb24KY2xvc2UuIFN0b3JlIGZpbGVuYW1l cyBvZiBuYXRpdmUgY29tcGlsYXRpb24gdW5pdHMgR0MnZCBpbiBhIGxpbmtlZApsaXN0IHRvIGZp bmlzaCB0aGVpciBkaXNwb3NhbCB3aGVuIHRoZSBHQyBpcyBvdmVyLgoqIHNyYy9jb21wLmg6IElu dHJvZHVjZSBjZmlsZSBtZW1iZXIgaW4gTGlzcF9OYXRpdmVfQ29tcF9Vbml0LgpBZGQgZGVjbGFy YXRpb25zIG9mIGZ1bmN0aW9ucyB0aGF0OiBjbGVhbiBkaXJlY3RvcmllcyBvZiB1bnVzZWQgbmF0 aXZlCmNvbXBpbGF0aW9uIHVuaXRzLCBoYW5kbGUgZGlzcG9zYWwgb2YgbmF0aXZlIGNvbXBpbGF0 aW9uIHVuaXRzLgoqIHNyYy9lbWFjcy5jIChraWxsLWVtYWNzKTogRGlzcG9zZSBhbGwgcmVtYWlu aW5nIGNvbXBpbGF0aW9uIHVuaXRzCnJpZ2h0IHJpZ2h0IGJlZm9yZSBjYWxsaW5nIGV4aXQoKS4K KiBzcmMvZXZhbC5jIChpbnRlcm5hbF9jb25kaXRpb25fY2FzZV8zLCBpbnRlcm5hbF9jb25kaXRp b25fY2FzZV80KToKQWRkIGZ1bmN0aW9ucy4KKiBzcmMvbGlzcC5oIChpbnRlcm5hbF9jb25kaXRp b25fY2FzZV8zLCBpbnRlcm5hbF9jb25kaXRpb25fY2FzZV80KToKQWRkIGZ1bmN0aW9ucy4KKiBz cmMvcGR1bXBlci5jIChkdW1wX2RvX2R1bXBfcmVsb2NhdGlvbik6IFNldCBjZmlsZSB0byBhIGNv cHkgb2YgdGhlCkxpc3Agc3RyaW5nIHNwZWNpZnlpbmcgdGhlIGZpbGUgcGF0aC4KLS0tCiBsaXNw L2VtYWNzLWxpc3AvY29tcC5lbCAgICB8ICAyNSArKysrKysKIGxpc3AvZW1hY3MtbGlzcC9wYWNr YWdlLmVsIHwgIDI3ICsrKysrLQogc3JjL2FsbG9jLmMgICAgICAgICAgICAgICAgfCAgIDUgKy0K IHNyYy9jb21wLmMgICAgICAgICAgICAgICAgIHwgMTc0ICsrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKystLS0KIHNyYy9jb21wLmggICAgICAgICAgICAgICAgIHwgIDI3ICsrKysrKwog c3JjL2VtYWNzLmMgICAgICAgICAgICAgICAgfCAgIDMgKwogc3JjL2V2YWwuYyAgICAgICAgICAg ICAgICAgfCAgNTUgKysrKysrKysrKysrCiBzcmMvbGlzcC5oICAgICAgICAgICAgICAgICB8ICAg MiArCiBzcmMvcGR1bXBlci5jICAgICAgICAgICAgICB8ICAgMyArCiA5IGZpbGVzIGNoYW5nZWQs IDMwOCBpbnNlcnRpb25zKCspLCAxMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2Vt YWNzLWxpc3AvY29tcC5lbCBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCmluZGV4IDAxMmJhZjI1 NjAuLjFmYjRjZDk4YzAgMTAwNjQ0Ci0tLSBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCisrKyBi L2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCkBAIC0yMTgzLDYgKzIxODMsMzEgQEAgY29tcC1oaW50 LWNvbnMKIAwKIDs7IFNvbWUgZW50cnkgcG9pbnQgc3VwcG9ydCBjb2RlLgogCisoZGVmdW4gY29t cC0tcmVwbGFjZS1vdXRwdXQtZmlsZSAob3V0ZmlsZSB0bXBmaWxlKQorICAiUmVwbGFjZSBPVVRG SUxFIHdpdGggVE1QRklMRSB0YWtpbmcgdGhlIG5lY2Vzc2FyeSBzdGVwcyB3aGVuCitkZWFsaW5n IHdpdGggc2hhcmVkIGxpYnJhcmllcyB0aGF0IG1heSBiZSBsb2FkZWQgaW50byBFbWFjcyIKKyAg KGNvbmQgKChlcSAnd2luZG93cy1udCBzeXN0ZW0tdHlwZSkKKyAgICAgICAgIChpZ25vcmUtZXJy b3JzIChkZWxldGUtZmlsZSBvdXRmaWxlKSkKKyAgICAgICAgIChsZXQgKChyZXRyeSB0KSkKKyAg ICAgICAgICAgKHdoaWxlIHJldHJ5CisgICAgICAgICAgICAgKHNldGYgcmV0cnkgbmlsKQorICAg ICAgICAgICAgIChjb25kaXRpb24tY2FzZSBfCisgICAgICAgICAgICAgICAgIChwcm9nbgorICAg ICAgICAgICAgICAgICAgIDs7IG91dGZpbGUgbWF5YmUgcmVjcmVhdGVkIGJ5IGFub3RoZXIgRW1h Y3MgaW4KKyAgICAgICAgICAgICAgICAgICA7OyBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgdHdvIHJl bmFtZS1maWxlIGNhbGxzCisgICAgICAgICAgICAgICAgICAgKGlmIChmaWxlLWV4aXN0cy1wIG91 dGZpbGUpCisgICAgICAgICAgICAgICAgICAgICAgIChyZW5hbWUtZmlsZSBvdXRmaWxlIChtYWtl LXRlbXAtZmlsZS1pbnRlcm5hbAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKGZpbGUtbmFtZS1zYW5zLWV4dGVuc2lvbiBvdXRmaWxlKQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmlsICIuZWxuLm9sZCIgbmlsKQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdCkpCisgICAgICAgICAgICAgICAgICAg KHJlbmFtZS1maWxlIHRtcGZpbGUgb3V0ZmlsZSBuaWwpKQorICAgICAgICAgICAgICAgKGZpbGUt YWxyZWFkeS1leGlzdHMgKHNldGYgcmV0cnkgdCkpKSkpKQorICAgICAgICA7OyBSZW1vdmUgdGhl IG9sZCBlbG4gaW5zdGVhZCBvZiBjb3B5aW5nIHRoZSBuZXcgb25lIGludG8gaXQKKyAgICAgICAg OzsgdG8gZ2V0IGEgbmV3IGlub2RlIGFuZCBwcmV2ZW50IGNyYXNoZXMgaW4gY2FzZSB0aGUgb2xk IG9uZQorICAgICAgICA7OyBpcyBjdXJyZW50bHkgbG9hZGVkLgorICAgICAgICAodCAoZGVsZXRl LWZpbGUgb3V0ZmlsZSkKKyAgICAgICAgICAgKHJlbmFtZS1maWxlIHRtcGZpbGUgb3V0ZmlsZSkp KSkKKwogKGRlZnZhciBjb21wLWZpbGVzLXF1ZXVlICgpCiAgICJMaXN0IG9mIEVsaXNwIGZpbGVz IHRvIGJlIGNvbXBpbGVkLiIpCiAKZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9wYWNrYWdl LmVsIGIvbGlzcC9lbWFjcy1saXNwL3BhY2thZ2UuZWwKaW5kZXggOTU2NTk4NDBhZC4uMzY4MDU3 ZTk1NSAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1saXNwL3BhY2thZ2UuZWwKKysrIGIvbGlzcC9l bWFjcy1saXNwL3BhY2thZ2UuZWwKQEAgLTIxODQsNiArMjE4NCwzMSBAQCBwYWNrYWdlLS1uZXdl c3QtcAogICAoZXF1YWwgKGNhZHIgKGFzc3EgKHBhY2thZ2UtZGVzYy1uYW1lIHBrZykgcGFja2Fn ZS1hbGlzdCkpCiAgICAgICAgICBwa2cpKQogCisoZGVmdW4gcGFja2FnZS0tZGVsZXRlLWRpcmVj dG9yeSAoZGlyKQorICAiRGVsZXRlIERJUiByZWN1cnNpdmVseS4KK0luIFdpbmRvd3MgbW92ZSAu ZWxuIGFuZCAuZWxuLm9sZCBmaWxlcyB0aGF0IGNhbiBub3QgYmUgZGVsZXRlZCB0byBgcGFja2Fn ZS11c2VyLWRpcicuIgorICAoY29uZCAoKGVxICd3aW5kb3dzLW50IHN5c3RlbS10eXBlKQorICAg ICAgICAgKGxldCAoKHJldHJ5IHQpKQorICAgICAgICAgICAod2hpbGUgcmV0cnkKKyAgICAgICAg ICAgICAoc2V0ZiByZXRyeSBuaWwpCisgICAgICAgICAgICAgKGNvbmRpdGlvbi1jYXNlIGVycgor ICAgICAgICAgICAgICAgICAoZGVsZXRlLWRpcmVjdG9yeSBkaXIgdCkKKyAgICAgICAgICAgICAg IChmaWxlLWVycm9yCisgICAgICAgICAgICAgICAgKGlmIChhbmQgKHN0cmluZz0gIlJlbW92aW5n IG9sZCBuYW1lIiAoY2FkciBlcnIpKQorICAgICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmc9 ICJQZXJtaXNzaW9uIGRlbmllZCIgKGNhZGRyIGVycikpCisgICAgICAgICAgICAgICAgICAgICAg ICAgKG9yIChzdHJpbmctc3VmZml4LXAgIi5lbG4iIChjYWRkZHIgZXJyKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHN0cmluZy1zdWZmaXgtcCAiLmVsbi5vbGQiIChjYWRkZHIgZXJy KSkpKQorICAgICAgICAgICAgICAgICAgICAocHJvZ24KKyAgICAgICAgICAgICAgICAgICAgICAo cmVuYW1lLWZpbGUgKGNhZGRkciBlcnIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChtYWtlLXRlbXAtZmlsZS1pbnRlcm5hbAorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKGNvbmNhdCBwYWNrYWdlLXVzZXItZGlyCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChmaWxlLW5hbWUtYmFzZSAoY2FkZGRyIGVycikpKQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmlsICIuZWxuLm9sZCIgbmlsKQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0KQorICAgICAgICAgICAgICAgICAgICAg IChzZXRmIHJldHJ5IHQpKQorICAgICAgICAgICAgICAgICAgKHNpZ25hbCAoY2FyIGVycikgKGNk ciBlcnIpKSkpKSkpKQorICAgICAgICAodCAoZGVsZXRlLWRpcmVjdG9yeSBkaXIgdCkpKQorCiAo ZGVmdW4gcGFja2FnZS1kZWxldGUgKHBrZy1kZXNjICZvcHRpb25hbCBmb3JjZSBub3NhdmUpCiAg ICJEZWxldGUgcGFja2FnZSBQS0ctREVTQy4KIApAQCAtMjIzNiw3ICsyMjYxLDcgQEAgcGFja2Fn ZS1kZWxldGUKICAgICAgICAgICAgICAgICAgIChwYWNrYWdlLWRlc2MtbmFtZSBwa2ctdXNlZC1l bHNld2hlcmUtYnkpKSkKICAgICAgICAgICAodAogICAgICAgICAgICAoYWRkLWhvb2sgJ3Bvc3Qt Y29tbWFuZC1ob29rICMncGFja2FnZS1tZW51LS1wb3N0LXJlZnJlc2gpCi0gICAgICAgICAgIChk ZWxldGUtZGlyZWN0b3J5IGRpciB0KQorICAgICAgICAgICAocGFja2FnZS0tZGVsZXRlLWRpcmVj dG9yeSBkaXIpCiAgICAgICAgICAgIDs7IFJlbW92ZSBOQU1FLVZFUlNJT04uc2lnbmVkIGFuZCBO QU1FLXJlYWRtZS50eHQgZmlsZXMuCiAgICAgICAgICAgIDs7CiAgICAgICAgICAgIDs7IE5BTUUt cmVhZG1lLnR4dCBmaWxlcyBhcmUgbm8gbG9uZ2VyIGNyZWF0ZWQsIGJ1dCB0aGV5CmRpZmYgLS1n aXQgYS9zcmMvYWxsb2MuYyBiL3NyYy9hbGxvYy5jCmluZGV4IGYyYjgwZmFjODguLjE3ZjVlMTVi MzUgMTAwNjQ0Ci0tLSBhL3NyYy9hbGxvYy5jCisrKyBiL3NyYy9hbGxvYy5jCkBAIC0zMTE5LDgg KzMxMTksNyBAQCBjbGVhbnVwX3ZlY3RvciAoc3RydWN0IExpc3BfVmVjdG9yICp2ZWN0b3IpCiAg ICAgewogICAgICAgc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqY3UgPQogCVBTRVVET1ZF Q19TVFJVQ1QgKHZlY3RvciwgTGlzcF9OYXRpdmVfQ29tcF9Vbml0KTsKLSAgICAgIGVhc3NlcnQg KGN1LT5oYW5kbGUpOwotICAgICAgZHlubGliX2Nsb3NlIChjdS0+aGFuZGxlKTsKKyAgICAgIGRp c3Bvc2VfY29tcF91bml0IChjdSwgdHJ1ZSk7CiAgICAgfQogfQogCkBAIC02MTE5LDYgKzYxMTgs OCBAQCBnYXJiYWdlX2NvbGxlY3QgKHZvaWQpCiAgICAgICBpZiAodG90X2FmdGVyIDwgdG90X2Jl Zm9yZSkKIAltYWxsb2NfcHJvYmUgKG1pbiAodG90X2JlZm9yZSAtIHRvdF9hZnRlciwgU0laRV9N QVgpKTsKICAgICB9CisKKyAgZmluaXNoX2RlbGF5ZWRfZGlzcG9zYWxfb2ZfY29tcF91bml0cyAo KTsKIH0KIAogREVGVU4gKCJnYXJiYWdlLWNvbGxlY3QiLCBGZ2FyYmFnZV9jb2xsZWN0LCBTZ2Fy YmFnZV9jb2xsZWN0LCAwLCAwLCAiIiwKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29t cC5jCmluZGV4IGI0M2QzZWRkYjMuLjM1ZTFlYzBkYTMgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMK KysrIGIvc3JjL2NvbXAuYwpAQCAtNDEzLDYgKzQxMywxMCBAQCAjZGVmaW5lIFRISVJEKHgpCQkJ CVwKICNkZWZpbmUgQ0FMTDFJKGZ1biwgYXJnKQkJCQlcCiAgIENBTExOIChGZnVuY2FsbCwgaW50 ZXJuX2Nfc3RyaW5nIChTVFIgKGZ1bikpLCBhcmcpCiAKKy8qIExpa2UgY2FsbDIgYnV0IHN0cmlu Z2lmeSBhbmQgaW50ZXJuLiAgKi8KKyNkZWZpbmUgQ0FMTDJJKGZ1biwgYXJnMSwgYXJnMikJCQkJ XAorICBDQUxMTiAoRmZ1bmNhbGwsIGludGVybl9jX3N0cmluZyAoU1RSIChmdW4pKSwgYXJnMSwg YXJnMikKKwogI2RlZmluZSBERUNMX0JMT0NLKG5hbWUsIGZ1bmMpCQkJCVwKICAgZ2NjX2ppdF9i bG9jayAqKG5hbWUpID0JCQkJXAogICAgIGdjY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrICgoZnVu YyksIFNUUiAobmFtZSkpCkBAIC0zODMwLDYgKzM4MzQsMTQgQEAgREVGVU4gKCJjb21wLS1yZWxl YXNlLWN0eHQiLCBGY29tcF9fcmVsZWFzZV9jdHh0LCBTY29tcF9fcmVsZWFzZV9jdHh0LAogICBy ZXR1cm4gUXQ7CiB9CiAKK3NpZ3NldF90IG9sZHNldDsKKworc3RhdGljIHZvaWQgcmVzdG9yZV9z aWdtYXNrKHZvaWQpCit7CisgIHB0aHJlYWRfc2lnbWFzayAoU0lHX1NFVE1BU0ssICZvbGRzZXQs IDApOworICB1bmJsb2NrX2lucHV0ICgpOworfQorCiBERUZVTiAoImNvbXAtLWNvbXBpbGUtY3R4 dC10by1maWxlIiwgRmNvbXBfX2NvbXBpbGVfY3R4dF90b19maWxlLAogICAgICAgIFNjb21wX19j b21waWxlX2N0eHRfdG9fZmlsZSwKICAgICAgICAxLCAxLCAwLApAQCAtMzg1MSw2ICszODYzLDgg QEAgREVGVU4gKCJjb21wLS1jb21waWxlLWN0eHQtdG8tZmlsZSIsIEZjb21wX19jb21waWxlX2N0 eHRfdG9fZmlsZSwKICAgICBDQUxMMUkgKGNvbXAtZGF0YS1jb250YWluZXItaWR4LCBDQUxMMUkg KGNvbXAtY3R4dC1kLWVwaGVtZXJhbCwgVmNvbXBfY3R4dCkpOwogCiAgIHNpZ3NldF90IG9sZHNl dDsKKyAgcHRyZGlmZl90IGNvdW50OworCiAgIGlmICghbm9uaW50ZXJhY3RpdmUpCiAgICAgewog ICAgICAgc2lnc2V0X3QgYmxvY2tlZDsKQEAgLTM4NjMsNiArMzg3Nyw4IEBAIERFRlVOICgiY29t cC0tY29tcGlsZS1jdHh0LXRvLWZpbGUiLCBGY29tcF9fY29tcGlsZV9jdHh0X3RvX2ZpbGUsCiAg ICAgICBzaWdhZGRzZXQgKCZibG9ja2VkLCBTSUdJTyk7CiAjZW5kaWYKICAgICAgIHB0aHJlYWRf c2lnbWFzayAoU0lHX0JMT0NLLCAmYmxvY2tlZCwgJm9sZHNldCk7CisgICAgICBjb3VudCA9IFNQ RUNQRExfSU5ERVggKCk7CisgICAgICByZWNvcmRfdW53aW5kX3Byb3RlY3Rfdm9pZChyZXN0b3Jl X3NpZ21hc2spOwogICAgIH0KICAgZW1pdF9jdHh0X2NvZGUgKCk7CiAKQEAgLTM5MDIsMTggKzM5 MTgsMTAgQEAgREVGVU4gKCJjb21wLS1jb21waWxlLWN0eHQtdG8tZmlsZSIsIEZjb21wX19jb21w aWxlX2N0eHRfdG9fZmlsZSwKIAkJCQkgICBHQ0NfSklUX09VVFBVVF9LSU5EX0RZTkFNSUNfTElC UkFSWSwKIAkJCQkgICBTU0RBVEEgKHRtcF9maWxlKSk7CiAKLSAgLyogUmVtb3ZlIHRoZSBvbGQg ZWxuIGluc3RlYWQgb2YgY29weWluZyB0aGUgbmV3IG9uZSBpbnRvIGl0IHRvIGdldAotICAgICBh IG5ldyBpbm9kZSBhbmQgcHJldmVudCBjcmFzaGVzIGluIGNhc2UgdGhlIG9sZCBvbmUgaXMgY3Vy cmVudGx5Ci0gICAgIGxvYWRlZC4gICovCi0gIGlmICghTklMUCAoRmZpbGVfZXhpc3RzX3AgKG91 dF9maWxlKSkpCi0gICAgRmRlbGV0ZV9maWxlIChvdXRfZmlsZSwgUW5pbCk7Ci0gIEZyZW5hbWVf ZmlsZSAodG1wX2ZpbGUsIG91dF9maWxlLCBRbmlsKTsKKyAgQ0FMTDJJKGNvbXAtLXJlcGxhY2Ut b3V0cHV0LWZpbGUsIG91dF9maWxlLCB0bXBfZmlsZSk7CiAKICAgaWYgKCFub25pbnRlcmFjdGl2 ZSkKLSAgICB7Ci0gICAgICBwdGhyZWFkX3NpZ21hc2sgKFNJR19TRVRNQVNLLCAmb2xkc2V0LCAw KTsKLSAgICAgIHVuYmxvY2tfaW5wdXQgKCk7Ci0gICAgfQorICAgIHVuYmluZF90byhjb3VudCwg UW5pbCk7CiAKICAgcmV0dXJuIG91dF9maWxlOwogfQpAQCAtMzk3NCw2ICszOTgyLDEzOCBAQCBo ZWxwZXJfUFNFVURPVkVDVE9SX1RZUEVQX1hVTlRBRyAoTGlzcF9PYmplY3QgYSwgZW51bSBwdmVj X3R5cGUgY29kZSkKIAkJCSAgICAgY29kZSk7CiB9CiAKKwwKKy8qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiovCisvKiBEaXNwb3NhbCBvZiBjb21waWxhdGlvbiB1bml0cyAqLworLyoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworI2lmZGVmIFdJTkRPV1NOVAorI2Rl ZmluZSBPTERfRUxOX1NVRkZJWF9SRUdFWFAgYnVpbGRfc3RyaW5nKCJcXC5lbG5cXC5vbGQkIikK Kworc3RhdGljIExpc3BfT2JqZWN0IGFsbF9sb2FkZWRfY29tcF91bml0czsKKworc3RydWN0IGRl bGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsCit7CisgIHN0cnVjdCBkZWxheWVkX2NvbXBfdW5pdF9k aXNwb3NhbCAqIG5leHQ7CisgIGNoYXIgKiBmaWxlbmFtZTsKK307CisKK3N0cnVjdCBkZWxheWVk X2NvbXBfdW5pdF9kaXNwb3NhbCAqIGRlbGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsX2xpc3Q7CisK K3N0YXRpYyBMaXNwX09iamVjdAorcmV0dXJuUW5pbCAoTGlzcF9PYmplY3QgYXJnKQoreworICBy ZXR1cm4gUW5pbDsKK30KKworc3RhdGljIHZvaWQKK2NsZWFuX2NvbXBfdW5pdF9kaXJlY3Rvcnkg KExpc3BfT2JqZWN0IGZpbGVwYXRoKQoreworICBpZiAoTklMUCAoZmlsZXBhdGgpKQorICAgIHJl dHVybjsKKyAgTGlzcF9PYmplY3QgZmlsZXNfaW5fZGlyOworICBmaWxlc19pbl9kaXIgPSBpbnRl cm5hbF9jb25kaXRpb25fY2FzZV80KEZkaXJlY3RvcnlfZmlsZXMsIGZpbGVwYXRoLCBRdCwKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPTERfRUxOX1NVRkZJWF9S RUdFWFAsIFFuaWwsIFF0LCByZXR1cm5RbmlsKTsKKyAgRk9SX0VBQ0hfVEFJTChmaWxlc19pbl9k aXIpCisgICAgeworICAgICAgRGVsZXRlRmlsZSAoU1NEQVRBIChYQ0FSIChmaWxlc19pbl9kaXIp KSk7CisgICAgfQorfQorCit2b2lkIGNsZWFuX3BhY2thZ2VfdXNlcl9kaXJfb2Zfb2xkX2NvbXBf dW5pdHMgKHZvaWQpCit7CisgIExpc3BfT2JqZWN0IHBhY2thZ2VfdXNlcl9kaXIgPSBmaW5kX3N5 bWJvbF92YWx1ZSAoaW50ZXJuICgicGFja2FnZS11c2VyLWRpciIpKTsKKyAgaWYgKEVRKHBhY2th Z2VfdXNlcl9kaXIsIFF1bmJvdW5kKSB8fCAhU1RSSU5HUChwYWNrYWdlX3VzZXJfZGlyKSkKKyAg ICByZXR1cm47CisKKyAgY2xlYW5fY29tcF91bml0X2RpcmVjdG9yeShwYWNrYWdlX3VzZXJfZGly KTsKK30KKworI2VuZGlmCisKK3ZvaWQgZGlzcG9zZV9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05h dGl2ZV9Db21wX1VuaXQgKiBjb21wX2hhbmRsZSwgYm9vbCBkZWxheSkKK3sKKyAgZWFzc2VydCAo Y29tcF9oYW5kbGUtPmhhbmRsZSk7CisgIGR5bmxpYl9jbG9zZSAoY29tcF9oYW5kbGUtPmhhbmRs ZSk7CisjaWZkZWYgV0lORE9XU05UCisgIGlmICghZGVsYXkpCisgICAgeworICAgICAgTGlzcF9P YmplY3QgZGlybmFtZSA9IGludGVybmFsX2NvbmRpdGlvbl9jYXNlXzEoRmZpbGVfbmFtZV9kaXJl Y3RvcnksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBidWlsZF9zdHJpbmcgKGNvbXBfaGFuZGxlLT5jZmlsZSksCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBRdCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVyblFuaWwpOworICAg ICAgaWYgKCFOSUxQKGRpcm5hbWUpKQorICAgICAgICBjbGVhbl9jb21wX3VuaXRfZGlyZWN0b3J5 IChkaXJuYW1lKTsKKyAgICAgIHhmcmVlIChjb21wX2hhbmRsZS0+Y2ZpbGUpOworICAgICAgY29t cF9oYW5kbGUtPmNmaWxlID0gTlVMTDsKKyAgICB9CisgIGVsc2UKKyAgICB7CisgICAgICBzdHJ1 Y3QgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWwgKiBoZWFkOworICAgICAgaGVhZCA9IHhtYWxs b2MgKHNpemVvZiAoc3RydWN0IGRlbGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsKSk7CisgICAgICBo ZWFkLT5uZXh0ID0gZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWxfbGlzdDsKKyAgICAgIGhlYWQt PmZpbGVuYW1lID0gY29tcF9oYW5kbGUtPmNmaWxlOworICAgICAgY29tcF9oYW5kbGUtPmNmaWxl ID0gTlVMTDsKKyAgICAgIGRlbGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsX2xpc3QgPSBoZWFkOwor ICAgIH0KKyNlbHNlCisgIHhmcmVlIChjb21wX2hhbmRsZS0+ZmlsZSk7CisjZW5kaWYKK30KKwor c3RhdGljIHZvaWQKK3JlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQgKExpc3BfT2JqZWN0IGNvbXBf dSkKK3sKKyNpZmRlZiBXSU5ET1dTTlQKKyAgc3RhdGljIEVNQUNTX1VJTlQgY291bnQ7CisKKyAg aWYgKFhGSVhOVU0oRmhhc2hfdGFibGVfY291bnQoYWxsX2xvYWRlZF9jb21wX3VuaXRzKSkgPj0g TU9TVF9QT1NJVElWRV9GSVhOVU0pCisgICAgcmV0dXJuOworCisgIHdoaWxlICghTklMUChGZ2V0 aGFzaChtYWtlX2ZpeG51bShjb3VudCksIGFsbF9sb2FkZWRfY29tcF91bml0cywgUW5pbCkpKQor ICAgIGNvdW50ID0gKGNvdW50ICsgMSkgJSBNT1NUX1BPU0lUSVZFX0ZJWE5VTTsKKworICBGcHV0 aGFzaChtYWtlX2ZpeG51bShjb3VudCksIGNvbXBfdSwgYWxsX2xvYWRlZF9jb21wX3VuaXRzKTsK KyNlbmRpZgorfQorCit2b2lkIGRpc3Bvc2VfYWxsX3JlbWFpbmluZ19jb21wX3VuaXRzICh2b2lk KQoreworI2lmZGVmIFdJTkRPV1NOVAorICBzdHJ1Y3QgTGlzcF9IYXNoX1RhYmxlICpoID0gWEhB U0hfVEFCTEUgKGFsbF9sb2FkZWRfY29tcF91bml0cyk7CisKKyAgZm9yIChwdHJkaWZmX3QgaSA9 IDA7IGkgPCBIQVNIX1RBQkxFX1NJWkUgKGgpOyArK2kpCisgICAgeworICAgICAgTGlzcF9PYmpl Y3QgayA9IEhBU0hfS0VZIChoLCBpKTsKKyAgICAgIGlmICghRVEgKGssIFF1bmJvdW5kKSkKKyAg ICAgICAgeworICAgICAgICAgIExpc3BfT2JqZWN0IHZhbCA9IEhBU0hfVkFMVUUgKGgsIGkpOwor ICAgICAgICAgIHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKiBjdSA9IFhOQVRJVkVfQ09N UF9VTklUKHZhbCk7CisgICAgICAgICAgZGlzcG9zZV9jb21wX3VuaXQoY3UsIGZhbHNlKTsKKyAg ICAgICAgfQorICAgIH0KKyNlbmRpZgorfQorCit2b2lkIGZpbmlzaF9kZWxheWVkX2Rpc3Bvc2Fs X29mX2NvbXBfdW5pdHMgKHZvaWQpCit7CisjaWZkZWYgV0lORE9XU05UCisgIGZvciAoc3RydWN0 IGRlbGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsICogaXRlbSA9IGRlbGF5ZWRfY29tcF91bml0X2Rp c3Bvc2FsX2xpc3Q7CisgICAgICAgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWxfbGlzdDsKKyAg ICAgICBpdGVtID0gZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWxfbGlzdCkKKyAgICB7CisgICAg ICBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0ID0gaXRlbS0+bmV4dDsKKyAgICAgIExp c3BfT2JqZWN0IGRpcm5hbWUKKyAgICAgICAgPSBpbnRlcm5hbF9jb25kaXRpb25fY2FzZV8xIChG ZmlsZV9uYW1lX2RpcmVjdG9yeSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBidWlsZF9zdHJpbmcgKGl0ZW0tPmZpbGVuYW1lKSwgUXQsCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmV0dXJuUW5pbCk7CisgICAgICBjbGVhbl9jb21wX3VuaXRfZGly ZWN0b3J5IChkaXJuYW1lKTsKKyAgICAgIHhmcmVlKGl0ZW0tPmZpbGVuYW1lKTsKKyAgICAgIHhm cmVlKGl0ZW0pOworICAgIH0KKyNlbmRpZgorfQorCiAMCiAvKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiovCiAvKiBEZWZlcnJlZCBjb21waWxhdGlvbiBtZWNoYW5pc20uICovCkBA IC00MTYwLDYgKzQzMDAsMTIgQEAgbG9hZF9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05hdGl2ZV9D b21wX1VuaXQgKmNvbXBfdSwgYm9vbCBsb2FkaW5nX2R1bXAsCiAgICAgICBkX3ZlY19sZW4gPSBY RklYTlVNIChGbGVuZ3RoIChjb21wX3UtPmRhdGFfaW1wdXJlX3ZlYykpOwogICAgICAgZm9yIChF TUFDU19JTlQgaSA9IDA7IGkgPCBkX3ZlY19sZW47IGkrKykKIAlkYXRhX2ltcF9yZWxvY3NbaV0g PSBBUkVGIChjb21wX3UtPmRhdGFfaW1wdXJlX3ZlYywgaSk7CisKKyAgICAgIC8qIElmIHdlIHJl Z2lzdGVyIHRoZW0gd2hpbGUgZHVtcGluZyB3ZSB3aWxsIGdldCBzb21lIGVudHJpZXMgaW4KKyAg ICAgICAgIHRoZSBoYXNoIHRhYmxlIHRoYXQgd2lsbCBiZSBkdXBsaWNhdGVkIHdoZW4gcGR1bXBl ciBjYWxscworICAgICAgICAgbG9hZF9jb21wX3VuaXQuICovCisgICAgICBpZiAoIXdpbGxfZHVt cF9wKCkpCisgICAgICAgIHJlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQgKGNvbXBfdV9saXNwX29i aik7CiAgICAgfQogCiAgIGlmICghbG9hZGluZ19kdW1wKQpAQCAtNDI3Myw2ICs0NDE5LDkgQEAg REVGVU4gKCJuYXRpdmUtZWxpc3AtbG9hZCIsIEZuYXRpdmVfZWxpc3BfbG9hZCwgU25hdGl2ZV9l bGlzcF9sb2FkLCAxLCAyLCAwLAogICBpZiAoIWNvbXBfdS0+aGFuZGxlKQogICAgIHhzaWduYWwy IChRbmF0aXZlX2xpc3BfbG9hZF9mYWlsZWQsIGZpbGUsIGJ1aWxkX3N0cmluZyAoZHlubGliX2Vy cm9yICgpKSk7CiAgIGNvbXBfdS0+ZmlsZSA9IGZpbGU7CisjaWZkZWYgV0lORE9XU05UCisgIGNv bXBfdS0+Y2ZpbGUgPSB4bGlzcHN0cmR1cChmaWxlKTsKKyNlbmRpZgogICBjb21wX3UtPmRhdGFf dmVjID0gUW5pbDsKICAgbG9hZF9jb21wX3VuaXQgKGNvbXBfdSwgZmFsc2UsICFOSUxQIChsYXRl X2xvYWQpKTsKIApAQCAtNDQxNyw2ICs0NTY2LDExIEBAIHN5bXNfb2ZfY29tcCAodm9pZCkKICAg c3RhdGljcHJvICgmZGVsYXllZF9zb3VyY2VzKTsKICAgZGVsYXllZF9zb3VyY2VzID0gUW5pbDsK IAorI2lmZGVmIFdJTkRPV1NOVAorICBzdGF0aWNwcm8gKCZhbGxfbG9hZGVkX2NvbXBfdW5pdHMp OworICBhbGxfbG9hZGVkX2NvbXBfdW5pdHMgPSBDQUxMTihGbWFrZV9oYXNoX3RhYmxlLCBRQ3dl YWtuZXNzLCBRdmFsdWUpOworI2VuZGlmCisKICAgREVGVkFSX0xJU1AgKCJjb21wLWN0eHQiLCBW Y29tcF9jdHh0LAogCSAgICAgICBkb2M6IC8qIFRoZSBjb21waWxlciBjb250ZXh0LiAgKi8pOwog ICBWY29tcF9jdHh0ID0gUW5pbDsKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmggYi9zcmMvY29tcC5o CmluZGV4IGU2YWIzMmZmOGUuLjg5ZWY3NDBmZTYgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmgKKysr IGIvc3JjL2NvbXAuaApAQCAtNDQsNyArNDQsMTUgQEAgI2RlZmluZSBDT01QX0gKICAgLyogU2Ft ZSBidXQgZm9yIGRhdGEgdGhhdCBjYW5ub3QgYmUgbW92ZWQgdG8gcHVyZSBzcGFjZS4KICAgICAg TXVzdCBiZSB0aGUgbGFzdCBsaXNwIG9iamVjdCBoZXJlLiAgICovCiAgIExpc3BfT2JqZWN0IGRh dGFfaW1wdXJlX3ZlYzsKKwogICBkeW5saWJfaGFuZGxlX3B0ciBoYW5kbGU7CisjaWZkZWYgV0lO RE9XU05UCisgIC8qIFdlIG5lZWQgdG8gc3RvcmUgYSBjb3B5IG9mIHRoZSBvcmlnaW5hbCBmaWxl IG5hbWUgaW4gbWVtb3J5IHRoYXQKKyAgICAgaXMgbm90IHN1YmplY3QgdG8gR0MgYmVjYXVzZSB0 aGUgZnVuY3Rpb24gdG8gZGlzcG9zZSBuYXRpdmUKKyAgICAgY29tcGlsYXRpb24gdW5pdHMgaXMg Y2FsbGVkIGJ5IHRoZSBHQy4gQnkgdGhhdCB0aW1lIHRoZSBgZmlsZScKKyAgICAgc3RyaW5nIG1h eSBoYXZlIGJlZW4gc3dlZXBlZC4gKi8KKyAgY2hhciAqIGNmaWxlOworI2VuZGlmCiB9OwogCiAj aWZkZWYgSEFWRV9OQVRJVkVfQ09NUApAQCAtNzUsNiArODMsMTQgQEAgWE5BVElWRV9DT01QX1VO SVQgKExpc3BfT2JqZWN0IGEpCiAKIGV4dGVybiB2b2lkIG1heWJlX2RlZmVyX25hdGl2ZV9jb21w aWxhdGlvbiAoTGlzcF9PYmplY3QgZnVuY3Rpb25fbmFtZSwKIAkJCQkJICAgIExpc3BfT2JqZWN0 IGRlZmluaXRpb24pOworCitleHRlcm4gdm9pZCBkaXNwb3NlX2NvbXBfdW5pdCAoc3RydWN0IExp c3BfTmF0aXZlX0NvbXBfVW5pdCAqIGNvbXBfdW5pdCwgYm9vbCBkZWxheSk7CisKK2V4dGVybiB2 b2lkIGZpbmlzaF9kZWxheWVkX2Rpc3Bvc2FsX29mX2NvbXBfdW5pdHMgKHZvaWQpOworCitleHRl cm4gdm9pZCBkaXNwb3NlX2FsbF9yZW1haW5pbmdfY29tcF91bml0cyAodm9pZCk7CisKK2V4dGVy biB2b2lkIGNsZWFuX3BhY2thZ2VfdXNlcl9kaXJfb2Zfb2xkX2NvbXBfdW5pdHMgKHZvaWQpOwog I2Vsc2UKIAogc3RhdGljIGlubGluZSB2b2lkCkBAIC04NCw2ICsxMDAsMTcgQEAgbWF5YmVfZGVm ZXJfbmF0aXZlX2NvbXBpbGF0aW9uIChMaXNwX09iamVjdCBmdW5jdGlvbl9uYW1lLAogCiBleHRl cm4gdm9pZCBzeW1zX29mX2NvbXAgKHZvaWQpOwogCitzdGF0aWMgaW5saW5lIHZvaWQgZGlzcG9z ZV9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKiBjb21wX2hhbmRsZSkK K3sKKyAgZW1hY3NfYWJvcnQoKTsKK30KKworc3RhdGljIGlubGluZSB2b2lkIGRpc3Bvc2VfYWxs X3JlbWFpbmluZ19jb21wX3VuaXRzICh2b2lkKQore30KKworc3RhdGljIGlubGluZSB2b2lkIGNs ZWFuX3BhY2thZ2VfdXNlcl9kaXJfb2Zfb2xkX2NvbXBfdW5pdHMgKHZvaWQpCit7fQorCiAjZW5k aWYKIAogI2VuZGlmCmRpZmYgLS1naXQgYS9zcmMvZW1hY3MuYyBiL3NyYy9lbWFjcy5jCmluZGV4 IGU3NWNiNTg4MzQuLmI3Yzg5YjQ0ZWMgMTAwNjQ0Ci0tLSBhL3NyYy9lbWFjcy5jCisrKyBiL3Ny Yy9lbWFjcy5jCkBAIC0yMzkzLDYgKzIzOTMsOSBAQCBERUZVTiAoImtpbGwtZW1hY3MiLCBGa2ls bF9lbWFjcywgU2tpbGxfZW1hY3MsIDAsIDEsICJQIiwKICAgICAgIHVubGluayAoU1NEQVRBIChs aXN0ZmlsZSkpOwogICAgIH0KIAorICBkaXNwb3NlX2FsbF9yZW1haW5pbmdfY29tcF91bml0cygp OworICBjbGVhbl9wYWNrYWdlX3VzZXJfZGlyX29mX29sZF9jb21wX3VuaXRzKCk7CisKICAgaWYg KEZJWE5VTVAgKGFyZykpCiAgICAgZXhpdF9jb2RlID0gKFhGSVhOVU0gKGFyZykgPCAwCiAJCSA/ IFhGSVhOVU0gKGFyZykgfCBJTlRfTUlOCmRpZmYgLS1naXQgYS9zcmMvZXZhbC5jIGIvc3JjL2V2 YWwuYwppbmRleCAxMDkxYjA4MjU1Li5hNjhmYzkwMjg1IDEwMDY0NAotLS0gYS9zcmMvZXZhbC5j CisrKyBiL3NyYy9ldmFsLmMKQEAgLTE0MTksNiArMTQxOSw2MSBAQCBpbnRlcm5hbF9jb25kaXRp b25fY2FzZV8yIChMaXNwX09iamVjdCAoKmJmdW4pIChMaXNwX09iamVjdCwgTGlzcF9PYmplY3Qp LAogICAgIH0KIH0KIAorLyogTGlrZSBpbnRlcm5hbF9jb25kaXRpb25fY2FzZV8xIGJ1dCBjYWxs IEJGVU4gd2l0aCBBUkcxLCBBUkcyLCBBUkczIGFzCisgICBpdHMgYXJndW1lbnRzLiAgKi8KKwor TGlzcF9PYmplY3QKK2ludGVybmFsX2NvbmRpdGlvbl9jYXNlXzMgKExpc3BfT2JqZWN0ICgqYmZ1 bikgKExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIExpc3BfT2JqZWN0KSwKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgIExpc3BfT2JqZWN0IGFyZzEsIExpc3BfT2JqZWN0IGFyZzIsIExpc3BfT2JqZWN0IGFy ZzMsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBMaXNwX09iamVjdCBoYW5kbGVycywKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgIExpc3BfT2JqZWN0ICgqaGZ1bikgKExpc3BfT2JqZWN0 KSkKK3sKKyAgc3RydWN0IGhhbmRsZXIgKmMgPSBwdXNoX2hhbmRsZXIgKGhhbmRsZXJzLCBDT05E SVRJT05fQ0FTRSk7CisgIGlmIChzeXNfc2V0am1wIChjLT5qbXApKQorICAgIHsKKyAgICAgIExp c3BfT2JqZWN0IHZhbCA9IGhhbmRsZXJsaXN0LT52YWw7CisgICAgICBjbG9iYmVyZWRfZWFzc2Vy dCAoaGFuZGxlcmxpc3QgPT0gYyk7CisgICAgICBoYW5kbGVybGlzdCA9IGhhbmRsZXJsaXN0LT5u ZXh0OworICAgICAgcmV0dXJuIGhmdW4gKHZhbCk7CisgICAgfQorICBlbHNlCisgICAgeworICAg ICAgTGlzcF9PYmplY3QgdmFsID0gYmZ1biAoYXJnMSwgYXJnMiwgYXJnMyk7CisgICAgICBlYXNz ZXJ0IChoYW5kbGVybGlzdCA9PSBjKTsKKyAgICAgIGhhbmRsZXJsaXN0ID0gYy0+bmV4dDsKKyAg ICAgIHJldHVybiB2YWw7CisgICAgfQorfQorCisvKiBMaWtlIGludGVybmFsX2NvbmRpdGlvbl9j YXNlXzEgYnV0IGNhbGwgQkZVTiB3aXRoIEFSRzEsIEFSRzIsIEFSRzMsIEFSRzQgYXMKKyAgIGl0 cyBhcmd1bWVudHMuICAqLworCitMaXNwX09iamVjdAoraW50ZXJuYWxfY29uZGl0aW9uX2Nhc2Vf NCAoTGlzcF9PYmplY3QgKCpiZnVuKSAoTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LAorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlzcF9PYmplY3QsIExp c3BfT2JqZWN0KSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIExpc3BfT2JqZWN0IGFyZzEs IExpc3BfT2JqZWN0IGFyZzIsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBMaXNwX09iamVj dCBhcmczLCBMaXNwX09iamVjdCBhcmc0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlz cF9PYmplY3QgaGFuZGxlcnMsCisgICAgICAgICAgICAgICAgICAgICAgICAgICBMaXNwX09iamVj dCAoKmhmdW4pIChMaXNwX09iamVjdCkpCit7CisgIHN0cnVjdCBoYW5kbGVyICpjID0gcHVzaF9o YW5kbGVyIChoYW5kbGVycywgQ09ORElUSU9OX0NBU0UpOworICBpZiAoc3lzX3NldGptcCAoYy0+ am1wKSkKKyAgICB7CisgICAgICBMaXNwX09iamVjdCB2YWwgPSBoYW5kbGVybGlzdC0+dmFsOwor ICAgICAgY2xvYmJlcmVkX2Vhc3NlcnQgKGhhbmRsZXJsaXN0ID09IGMpOworICAgICAgaGFuZGxl cmxpc3QgPSBoYW5kbGVybGlzdC0+bmV4dDsKKyAgICAgIHJldHVybiBoZnVuICh2YWwpOworICAg IH0KKyAgZWxzZQorICAgIHsKKyAgICAgIExpc3BfT2JqZWN0IHZhbCA9IGJmdW4gKGFyZzEsIGFy ZzIsIGFyZzMsIGFyZzQpOworICAgICAgZWFzc2VydCAoaGFuZGxlcmxpc3QgPT0gYyk7CisgICAg ICBoYW5kbGVybGlzdCA9IGMtPm5leHQ7CisgICAgICByZXR1cm4gdmFsOworICAgIH0KK30KKwog LyogTGlrZSBpbnRlcm5hbF9jb25kaXRpb25fY2FzZSBidXQgY2FsbCBCRlVOIHdpdGggTkFSR1Mg YXMgZmlyc3QsCiAgICBhbmQgQVJHUyBhcyBzZWNvbmQgYXJndW1lbnQuICAqLwogCmRpZmYgLS1n aXQgYS9zcmMvbGlzcC5oIGIvc3JjL2xpc3AuaAppbmRleCBlMjQyNTQ2ZDEwLi5lZWFjMjA1OThj IDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3NyYy9saXNwLmgKQEAgLTQxMzgsNiArNDEz OCw4IEBAIHhzaWduYWwgKExpc3BfT2JqZWN0IGVycm9yX3N5bWJvbCwgTGlzcF9PYmplY3QgZGF0 YSkKIGV4dGVybiBMaXNwX09iamVjdCBpbnRlcm5hbF9jb25kaXRpb25fY2FzZSAoTGlzcF9PYmpl Y3QgKCopICh2b2lkKSwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0ICgqKSAoTGlzcF9PYmplY3Qp KTsKIGV4dGVybiBMaXNwX09iamVjdCBpbnRlcm5hbF9jb25kaXRpb25fY2FzZV8xIChMaXNwX09i amVjdCAoKikgKExpc3BfT2JqZWN0KSwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09i amVjdCAoKikgKExpc3BfT2JqZWN0KSk7CiBleHRlcm4gTGlzcF9PYmplY3QgaW50ZXJuYWxfY29u ZGl0aW9uX2Nhc2VfMiAoTGlzcF9PYmplY3QgKCopIChMaXNwX09iamVjdCwgTGlzcF9PYmplY3Qp LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCAoKikg KExpc3BfT2JqZWN0KSk7CitleHRlcm4gTGlzcF9PYmplY3QgaW50ZXJuYWxfY29uZGl0aW9uX2Nh c2VfMyAoTGlzcF9PYmplY3QgKCopIChMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2Jq ZWN0KSwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3Qs IExpc3BfT2JqZWN0ICgqKSAoTGlzcF9PYmplY3QpKTsKK2V4dGVybiBMaXNwX09iamVjdCBpbnRl cm5hbF9jb25kaXRpb25fY2FzZV80IChMaXNwX09iamVjdCAoKikgKExpc3BfT2JqZWN0LCBMaXNw X09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0KSwgTGlzcF9PYmplY3QsIExpc3BfT2Jq ZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCAo KikgKExpc3BfT2JqZWN0KSk7CiBleHRlcm4gTGlzcF9PYmplY3QgaW50ZXJuYWxfY29uZGl0aW9u X2Nhc2VfbgogICAgIChMaXNwX09iamVjdCAoKikgKHB0cmRpZmZfdCwgTGlzcF9PYmplY3QgKiks IHB0cmRpZmZfdCwgTGlzcF9PYmplY3QgKiwKICAgICAgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0 ICgqKSAoTGlzcF9PYmplY3QsIHB0cmRpZmZfdCwgTGlzcF9PYmplY3QgKikpOwpkaWZmIC0tZ2l0 IGEvc3JjL3BkdW1wZXIuYyBiL3NyYy9wZHVtcGVyLmMKaW5kZXggZjgzN2RmYzM4ZC4uOWIwYmQ0 NzJkNiAxMDA2NDQKLS0tIGEvc3JjL3BkdW1wZXIuYworKysgYi9zcmMvcGR1bXBlci5jCkBAIC01 MzEyLDYgKzUzMTIsOSBAQCBkdW1wX2RvX2R1bXBfcmVsb2NhdGlvbiAoY29uc3QgdWludHB0cl90 IGR1bXBfYmFzZSwKIAkgIGNvbmNhdDIgKFZpbnZvY2F0aW9uX2RpcmVjdG9yeSwKIAkJICAgaW5z dGFsbGF0aW9uX3N0YXRlID09IExPQ0FMX0JVSUxECiAJCSAgID8gWENEUiAoY29tcF91LT5maWxl KSA6IFhDQVIgKGNvbXBfdS0+ZmlsZSkpOworI2lmZGVmIFdJTkRPV1NOVAorICAgICAgICBjb21w X3UtPmNmaWxlID0geGxpc3BzdHJkdXAoY29tcF91LT5maWxlKTsKKyNlbmRpZgogCWNvbXBfdS0+ aGFuZGxlID0gZHlubGliX29wZW4gKFNTREFUQSAoY29tcF91LT5maWxlKSk7CiAJaWYgKCFjb21w X3UtPmhhbmRsZSkKIAkgIGVycm9yICgiJXMiLCBkeW5saWJfZXJyb3IgKCkpOwotLSAKMi4yNS4x LndpbmRvd3MuMQoK --0000000000004e7dbe05a60536de-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 19 15:26:13 2020 Received: (at 41242) by debbugs.gnu.org; 19 May 2020 19:26:13 +0000 Received: from localhost ([127.0.0.1]:51145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jb7sS-0005qn-SN for submit@debbugs.gnu.org; Tue, 19 May 2020 15:26:13 -0400 Received: from mail-ot1-f42.google.com ([209.85.210.42]:39465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jb7sS-0005qa-0W for 41242@debbugs.gnu.org; Tue, 19 May 2020 15:26:12 -0400 Received: by mail-ot1-f42.google.com with SMTP id d7so478673ote.6 for <41242@debbugs.gnu.org>; Tue, 19 May 2020 12:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nM4pVpH2I3s3/nSed9mmaN5RVe9mk961NJfvZonhSA=; b=AlG4ck9KxwGKmP/p3yu5ol80pJde0Qilw6GSHM3fJojRSRF+KUbf++gq079PdFXvcy WvQYxVkX0MIF7/AKT9zgJEKotDa5rlusfIT4nWdtIzIfKyrOqZkYedrm8GJWU+6qpYWa RUEiQ4NGPPTgmrrtf8W7A2PRfuvXX5HVu5z/xmrR12mv3MRJL0t8iw9eJ5zIn7v9ddaU B+DdFDGm/Ly8J75PEYa0com83zi7B+pejMgzpteqaKf1Sql1dgtFtw/iMF6rcIaSFGBH rHNGq8UnTNwlVivYR28DpRHJPweB5a6jGS3+bfNYg+lSQ5VTQaZs6WIgOvRZxi/HRhJv 2neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nM4pVpH2I3s3/nSed9mmaN5RVe9mk961NJfvZonhSA=; b=b5Dix3kh7Gog2tQyg7Gns7Ym2a70xKjXVHLtXERPCqkBTBTNNOOKH8zx8FchLC/kxt BsMGRNL5+OE/a+tsCx/Olrpo/VJav9M7T+ZMF2bOTknp77rxC/Bz33EmpsN3yadUZ+iC 69FFO0AXe3uLbVq5NVb1kHJTVxZf42dX7vVWCvTd01Fkwk18AW59C+21R/5m6BjexD7n vcScihfRq8ym33HtCjRCZN5phzXHf/rdyncx5BTL63mBp2GE2MIxUFM4qIKfKLuBpkoi krI4fiuGJrJaGEfc44EXb9+churCgrOGT8kn4sR5TyI91J4AhjW/OPWSLIsbsz+JsmNE lUDQ== X-Gm-Message-State: AOAM532Ts1Bw3SjZTi1cDl0XP+1UUTOIpH4lDwYLkMjdTuThBt0+/T8Z OE6G0EZjHda8dmOwlc2aPIucC/xtgwDnoMKdy8o= X-Google-Smtp-Source: ABdhPJxX9doHF3d4FoTnr2JxbUMZz9exxM6Z+VrWO8NguS+2gSj5lZRWvLyygH/n3euNO5K/lGZYN2GHyCflfm7226Q= X-Received: by 2002:a9d:191:: with SMTP id e17mr451011ote.193.1589916366292; Tue, 19 May 2020 12:26:06 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Tue, 19 May 2020 16:25:53 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000003cd56705a6054074" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --0000000000003cd56705a6054074 Content-Type: multipart/alternative; boundary="0000000000003cd56405a6054072" --0000000000003cd56405a6054072 Content-Type: text/plain; charset="UTF-8" The following two patches handle minor issues: * Removal of the emacs_root_dir() hack. * Determine the number of processors for native compilation. --0000000000003cd56405a6054072 Content-Type: text/html; charset="UTF-8"
The following two patches handle minor issues:

* Removal of the emacs_root_dir() hack.
* Determine the number of processors for native compilation.
--0000000000003cd56405a6054072-- --0000000000003cd56705a6054074 Content-Type: application/octet-stream; name="0001-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Disposition: attachment; filename="0001-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kaeb55v70 RnJvbSAxZmI1YzM4NzQ4YzEyNzM1ZWUxZDZlYjZlNzk0ZDYxNzIwZTRmYzExIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAxMyBNYXkgMjAyMCAxNjoy MjoxNyAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIFdpbmRvd3M6IFVzZSBOVU1CRVJfT0ZfUFJPQ0VT U09SUyBlbnZpcm9ubWVudCB2YXJpYWJsZS4KCiogbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgKGNv bXAtZWZmZWN0aXZlLWFzeW5jLW1heC1qb2JzKTogVXNlCk5VTUJFUl9PRl9QUk9DRVNTT1JTIGVu dmlyb25tZW50IHZhcmlhYmxlIGlmIHN5c3RlbSBpcyBXaW5kb3dzIE5ULAoibnByb2MiIGlmIGl0 IGlzIGluIFBBVEggb3IgYSBkZWZhdWx0IG9mIDEuCi0tLQogbGlzcC9lbWFjcy1saXNwL2NvbXAu ZWwgfCA4ICsrKysrLS0tCiAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAzIGRlbGV0 aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsIGIvbGlzcC9lbWFj cy1saXNwL2NvbXAuZWwKaW5kZXggZDMyZjkzYTFlMS4uMjZiYjc5ZmNkMSAxMDA2NDQKLS0tIGEv bGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKKysrIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKQEAg LTIyMDgsOSArMjIwOCwxMSBAQCBjb21wLWFzeW5jLXJ1bm5pbmdzCiAgICAgKGlmICh6ZXJvcCBj b21wLWFzeW5jLWpvYnMtbnVtYmVyKQogICAgICAgICAob3IgbnVtLWNwdXMKICAgICAgICAgICAg IChzZXRmIG51bS1jcHVzCi0gICAgICAgICAgICAgICAgICA7OyBIYWxmIG9mIHRoZSBDUFVzIG9y IGF0IGxlYXN0IG9uZS4KLSAgICAgICAgICAgICAgICAgIDs7IEZJWE1FIHBvcnRhYmxlPwotICAg ICAgICAgICAgICAgICAgKG1heCAxICgvIChzdHJpbmctdG8tbnVtYmVyIChzaGVsbC1jb21tYW5k LXRvLXN0cmluZyAibnByb2MiKSkKKyAgICAgICAgICAgICAgICAgIChtYXggMSAoLyAoY29uZCAo KGVxICd3aW5kb3dzLW50IHN5c3RlbS10eXBlKQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoc3RyaW5nLXRvLW51bWJlciAoZ2V0ZW52ICJOVU1CRVJfT0ZfUFJPQ0VTU09SUyIp KSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoKGV4ZWN1dGFibGUtZmluZCAi bnByb2MiKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoc3RyaW5nLXRvLW51 bWJlciAoc2hlbGwtY29tbWFuZC10by1zdHJpbmcgIm5wcm9jIikpKQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICh0IDEpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIp KSkpCiAgICAgICBjb21wLWFzeW5jLWpvYnMtbnVtYmVyKSkpCiAKLS0gCjIuMjUuMS53aW5kb3dz LjEKCg== --0000000000003cd56705a6054074 Content-Type: application/octet-stream; name="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Disposition: attachment; filename="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kaeb55vg1 RnJvbSBhNzE3NmE2NGQ0ZDg4Mjg3NGQ0YTgxY2MzOTI0ZTAzZmEyYTA5Y2U4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAxMyBNYXkgMjAyMCAxODoz MTo0MiAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIERldGVybWluZSB0aGUgZW1hY3Mgcm9vdCBkaXIg b25seSB3aGVuIG5lY2Vzc2FyeS4KCiogc3JjL2ZpbGVpby5jOiBJbnRyb2R1Y2UgZnVuY3Rpb24g ZW1hY3Nfcm9vdF9kaXIoKS4gUmVmYWN0b3IKYGV4cGFuZC1maWxlLW5hbWVgIHRvIHVzZSBpdC4K KiBzcmMvbGlzcC5oOiBTZXBhcmF0ZSBlbWFjc19yb290X2RpcigpIGludG8gZG9zX2VtYWNzX3Jv b3RfZGlyKCkgYW5kCnczMl9lbWFjc19yb290X2RpcigpLgoqIHNyYy9tc2Rvcy5jOiBSZW5hbWUg ZW1hY3Nfcm9vdF9kaXIoKSB0byBkb3NfZW1hY3Nfcm9vdF9kaXIoKS4KKiBzcmMvdzMyLmM6IFJl bmFtZSBlbWFjc19yb290X2RpcigpIHRvIHczMl9lbWFjc19yb290X2RpcigpLgotLS0KIHNyYy9m aWxlaW8uYyB8IDM3ICsrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0KIHNyYy9s aXNwLmggICB8IDExICsrKysrKystLS0tCiBzcmMvbXNkb3MuYyAgfCAgMiArLQogc3JjL3czMi5j ICAgIHwgIDIgKy0KIDQgZmlsZXMgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKSwgMjEgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2ZpbGVpby5jIGIvc3JjL2ZpbGVpby5jCmluZGV4IDJm MWQyZjgyNDMuLmUyMGZhOTNjNjUgMTAwNjQ0Ci0tLSBhL3NyYy9maWxlaW8uYworKysgYi9zcmMv ZmlsZWlvLmMKQEAgLTc4MSw2ICs3ODEsMTggQEAgdXNlcl9ob21lZGlyIChjaGFyIGNvbnN0ICpu YW1lKQogICByZXR1cm4gcHctPnB3X2RpcjsKIH0KIAorc3RhdGljIExpc3BfT2JqZWN0CitlbWFj c19yb290X2RpcigpCit7CisjaWZkZWYgRE9TCisgICAgICByZXR1cm4gYnVpbGRfc3RyaW5nIChk b3NfZW1hY3Nfcm9vdF9kaXIgKCkpOworI2VsaWYgZGVmaW5lZChXSU5ET1dTTlQpCisgICAgICBy ZXR1cm4gYnVpbGRfc3RyaW5nICh3MzJfZW1hY3Nfcm9vdF9kaXIgKCkpOworI2Vsc2UKKyAgICAg IHJldHVybiBidWlsZF9zdHJpbmcgKCIvIik7CisjZW5kaWYKK30KKwogREVGVU4gKCJleHBhbmQt ZmlsZS1uYW1lIiwgRmV4cGFuZF9maWxlX25hbWUsIFNleHBhbmRfZmlsZV9uYW1lLCAxLCAyLCAw LAogICAgICAgIGRvYzogLyogQ29udmVydCBmaWxlbmFtZSBOQU1FIHRvIGFic29sdXRlLCBhbmQg Y2Fub25pY2FsaXplIGl0LgogU2Vjb25kIGFyZyBERUZBVUxULURJUkVDVE9SWSBpcyBkaXJlY3Rv cnkgdG8gc3RhcnQgd2l0aCBpZiBOQU1FIGlzIHJlbGF0aXZlCkBAIC04NTEsMjEgKzg2MywxNiBA QCBERUZVTiAoImV4cGFuZC1maWxlLW5hbWUiLCBGZXhwYW5kX2ZpbGVfbmFtZSwgU2V4cGFuZF9m aWxlX25hbWUsIDEsIDIsIDAsCiAgICAgfQogCiAgIC8qIEFzIGEgbGFzdCByZXNvcnQsIHdlIG1h eSBoYXZlIHRvIHVzZSB0aGUgcm9vdCBhcwotICAgICBkZWZhdWx0X2RpcmVjdG9yeSBiZWxvdy4g ICovCi0gIExpc3BfT2JqZWN0IHJvb3Q7Ci0jaWZkZWYgRE9TX05UCi0gICAgICAvKiAiLyIgaXMg bm90IGNvbnNpZGVyZWQgYSByb290IGRpcmVjdG9yeSBvbiBET1NfTlQsIHNvIHVzaW5nIGl0Ci0J IGFzIGRlZmF1bHRfZGlyZWN0b3J5IGNhdXNlcyBhbiBpbmZpbml0ZSByZWN1cnNpb24gaW4sIGUu Zy4sCi0JIHRoZSBmb2xsb3dpbmc6CisgICAgIGRlZmF1bHRfZGlyZWN0b3J5IGJlbG93LgogCi0g ICAgICAgICAgICAobGV0IChkZWZhdWx0LWRpcmVjdG9yeSkKLQkgICAgICAoZXhwYW5kLWZpbGUt bmFtZSAiYSIpKQorICAgICAiLyIgaXMgbm90IGNvbnNpZGVyZWQgYSByb290IGRpcmVjdG9yeSBv biBET1NfTlQsIHNvIHVzaW5nIGl0CisgICAgIGFzIGRlZmF1bHRfZGlyZWN0b3J5IGNhdXNlcyBh biBpbmZpbml0ZSByZWN1cnNpb24gaW4sIGUuZy4sCisgICAgIHRoZSBmb2xsb3dpbmc6CiAKLQkg VG8gYXZvaWQgdGhpcywgd2UgdXNlIHRoZSByb290IG9mIHRoZSBjdXJyZW50IGRyaXZlLiAgKi8K LSAgICAgIHJvb3QgPSBidWlsZF9zdHJpbmcgKGVtYWNzX3Jvb3RfZGlyICgpKTsKLSNlbHNlCi0g ICAgICByb290ID0gYnVpbGRfc3RyaW5nICgiLyIpOwotI2VuZGlmCisgICAgICAgIChsZXQgKGRl ZmF1bHQtZGlyZWN0b3J5KQorICAgICAgICAgIChleHBhbmQtZmlsZS1uYW1lICJhIikpCisKKyAg ICAgVG8gYXZvaWQgdGhpcywgd2UgdXNlIHRoZSByb290IG9mIHRoZSBjdXJyZW50IGRyaXZlLiAg Ki8KIAogICAvKiBVc2UgdGhlIGJ1ZmZlcidzIGRlZmF1bHQtZGlyZWN0b3J5IGlmIERFRkFVTFRf RElSRUNUT1JZIGlzIG9taXR0ZWQuICAqLwogICBpZiAoTklMUCAoZGVmYXVsdF9kaXJlY3Rvcnkp KQpAQCAtODkxLDEzICs4OTgsMTMgQEAgREVGVU4gKCJleHBhbmQtZmlsZS1uYW1lIiwgRmV4cGFu ZF9maWxlX25hbWUsIFNleHBhbmRfZmlsZV9uYW1lLCAxLCAyLCAwLAogCSAgICAgIExpc3BfT2Jq ZWN0IGFic2RpcgogCQk9IFNUUklOR1AgKFZpbnZvY2F0aW9uX2RpcmVjdG9yeSkKIAkJJiYgZmls ZV9uYW1lX2Fic29sdXRlX25vX3RpbGRlX3AgKFZpbnZvY2F0aW9uX2RpcmVjdG9yeSkKLQkJPyBW aW52b2NhdGlvbl9kaXJlY3RvcnkgOiByb290OworCQk/IFZpbnZvY2F0aW9uX2RpcmVjdG9yeSA6 IGVtYWNzX3Jvb3RfZGlyKCk7CiAJICAgICAgZGVmYXVsdF9kaXJlY3RvcnkgPSBGZXhwYW5kX2Zp bGVfbmFtZSAoZGlyLCBhYnNkaXIpOwogCSAgICB9CiAJfQogICAgIH0KICAgaWYgKCEgU1RSSU5H UCAoZGVmYXVsdF9kaXJlY3RvcnkpKQotICAgIGRlZmF1bHRfZGlyZWN0b3J5ID0gcm9vdDsKKyAg ICBkZWZhdWx0X2RpcmVjdG9yeSA9IGVtYWNzX3Jvb3RfZGlyKCk7CiAKICAgaGFuZGxlciA9IEZm aW5kX2ZpbGVfbmFtZV9oYW5kbGVyIChkZWZhdWx0X2RpcmVjdG9yeSwgUWV4cGFuZF9maWxlX25h bWUpOwogICBpZiAoIU5JTFAgKGhhbmRsZXIpKQpkaWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3Ny Yy9saXNwLmgKaW5kZXggM2QwODI5MTFmNS4uODM0YjNlNTg2YyAxMDA2NDQKLS0tIGEvc3JjL2xp c3AuaAorKysgYi9zcmMvbGlzcC5oCkBAIC00NzE5LDEwICs0NzE5LDEzIEBAIG1heWJlX2Rpc2Fi bGVfYWRkcmVzc19yYW5kb21pemF0aW9uIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiBleHRlcm4g dm9pZCBtYWxsb2NfcHJvYmUgKHNpemVfdCk7CiBleHRlcm4gdm9pZCBzeW1zX29mX3Byb2ZpbGVy ICh2b2lkKTsKIAotI2lmZGVmIERPU19OVAotLyogRGVmaW5lZCBpbiBtc2Rvcy5jLCB3MzIuYy4g ICovCi1leHRlcm4gY2hhciAqZW1hY3Nfcm9vdF9kaXIgKHZvaWQpOwotI2VuZGlmIC8qIERPU19O VCAqLworI2lmZGVmIE1TRE9TCisvKiBEZWZpbmVkIGluIG1zZG9zLmMuICAqLworZXh0ZXJuIGNo YXIgKmRvc19lbWFjc19yb290X2RpciAodm9pZCk7CisjZWxpZiBkZWZpbmVkKFdJTkRPV1NOVCkK Ky8qIERlZmluZWQgaW4gdzMyLmMuICAqLworZXh0ZXJuIGNoYXIgKnczMl9lbWFjc19yb290X2Rp ciAodm9pZCk7CisjZW5kaWYgLyogTVNET1MgKi8KIAogI2lmZGVmIEhBVkVfTkFUSVZFX0NPTVAK IElOTElORSBib29sCmRpZmYgLS1naXQgYS9zcmMvbXNkb3MuYyBiL3NyYy9tc2Rvcy5jCmluZGV4 IGI1ZjA2Yzk5YzMuLjA4MjdjYzk2Y2QgMTAwNjQ0Ci0tLSBhL3NyYy9tc2Rvcy5jCisrKyBiL3Ny Yy9tc2Rvcy5jCkBAIC0zMzUwLDcgKzMzNTAsNyBAQCBnZXRkZWZkaXIgKGludCBkcml2ZSwgY2hh ciAqZHN0KQogfQogCiBjaGFyICoKLWVtYWNzX3Jvb3RfZGlyICh2b2lkKQorZG9zX2VtYWNzX3Jv b3RfZGlyICh2b2lkKQogewogICBzdGF0aWMgY2hhciByb290X2Rpcls0XTsKIApkaWZmIC0tZ2l0 IGEvc3JjL3czMi5jIGIvc3JjL3czMi5jCmluZGV4IDBmNjllNjUyYTUuLjFlYzAwOTRjOGUgMTAw NjQ0Ci0tLSBhL3NyYy93MzIuYworKysgYi9zcmMvdzMyLmMKQEAgLTMxNDcsNyArMzE0Nyw3IEBA ICNkZWZpbmUgU0VUX0VOVl9CVUZfU0laRSAoNCAqIE1BWF9QQVRIKQkvKiB0byBjb3ZlciBFTUFD U0xPQURQQVRIICovCiAvKiBDYWxsZWQgZnJvbSBleHBhbmQtZmlsZS1uYW1lIHdoZW4gZGVmYXVs dC1kaXJlY3RvcnkgaXMgbm90IGEgc3RyaW5nLiAgKi8KIAogY2hhciAqCi1lbWFjc19yb290X2Rp ciAodm9pZCkKK3czMl9lbWFjc19yb290X2RpciAodm9pZCkKIHsKICAgc3RhdGljIGNoYXIgcm9v dF9kaXJbTUFYX1VURjhfUEFUSF07CiAgIGNvbnN0IGNoYXIgKnA7Ci0tIAoyLjI1LjEud2luZG93 cy4xCgo= --0000000000003cd56705a6054074-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 11:29:59 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 15:29:59 +0000 Received: from localhost ([127.0.0.1]:54032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbQfM-0004N2-9P for submit@debbugs.gnu.org; Wed, 20 May 2020 11:29:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbQfK-0004Mo-1J for 41242@debbugs.gnu.org; Wed, 20 May 2020 11:29:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51188) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbQfB-0004Ta-QZ; Wed, 20 May 2020 11:29:46 -0400 Received: from [176.228.60.248] (port=2047 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jbQcn-0001OM-8b; Wed, 20 May 2020 11:27:18 -0400 Date: Wed, 20 May 2020 18:27:16 +0300 Message-Id: <83a7227hkb.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Tue, 19 May 2020 16:25:53 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Tue, 19 May 2020 16:25:53 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > * lisp/emacs-lisp/comp.el (comp-effective-async-max-jobs): Use > NUMBER_OF_PROCESSORS environment variable if system is Windows NT, > "nproc" if it is in PATH or a default of 1. This shouldn't be necessary: we already have a function to determine the number of processors, see get_native_system_info in w32.c. If you need the result exported to Lisp, we can define a new variable which will be populated with the value. > Subject: [PATCH] Determine the emacs root dir only when necessary. > > * src/fileio.c: Introduce function emacs_root_dir(). Refactor > `expand-file-name` to use it. > * src/lisp.h: Separate emacs_root_dir() into dos_emacs_root_dir() and > w32_emacs_root_dir(). > * src/msdos.c: Rename emacs_root_dir() to dos_emacs_root_dir(). > * src/w32.c: Rename emacs_root_dir() to w32_emacs_root_dir(). Can you explain what problem this solves, and how? It is especially important to understand when will be emacs_root_dir first called during a session. That's because it calls filename_from_ansi, which AFAIR needs some setup that happens at the beginning of a session. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 11:46:52 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 15:46:52 +0000 Received: from localhost ([127.0.0.1]:54061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbQvk-0004pp-BH for submit@debbugs.gnu.org; Wed, 20 May 2020 11:46:52 -0400 Received: from mail-oi1-f175.google.com ([209.85.167.175]:32820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbQvj-0004pd-9g for 41242@debbugs.gnu.org; Wed, 20 May 2020 11:46:51 -0400 Received: by mail-oi1-f175.google.com with SMTP id o24so3369825oic.0 for <41242@debbugs.gnu.org>; Wed, 20 May 2020 08:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V7xESXowtRSy5CPAHvw5PUYQ+6akIVyQE/fjqXm1/hE=; b=Pv59PKfkxs5XYABcVCpIx5Z2NkRxG04dDSTeXmbBqHctkRbTQwKoWM5AhsXJVD/qj6 9tRr6ayQwkgubD+wIdlgGxKf375jFjLwgBkVNXf5sTE2Az8rQLeJ6+F5uvpvSIIGEO02 3SRX1EL9VgH1VYTSSQZ3+L3t9GH0MOT3QfrSKQpXkORzFFGEZPRmYhUR0wJZEtFK/Goe bB3BSMtVxzZx0svNTKIu8Jcki8cc7mgVlcLR3JETk4wKexdFFHy8YpEWxGe84+oIRuD5 i+AxGm6r7PJaeuZeZEBsUSy0NqrdAlY+cAH7t7jvnc1hsF+6Yia6il5LlqWz8+lSHRuk OdkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V7xESXowtRSy5CPAHvw5PUYQ+6akIVyQE/fjqXm1/hE=; b=Oc+kOq7hZdGgHuksL91wvvmnEB6F88LJ8Kp1iht9nayj2nNmgqw7H112134hBluxhO EHb7znvrv1LopDNpp813+6Vh0T85nwmG3BmSRvr6SCkyYsxMEdt086WorQuUDx5Kkzwi XcIASf5xewhKZTZz1scZAvkfyI/E5HutGgUPckuGu//ZH4kU6EgdtbakffiBZAVruIdp DID9xurS9rzgUXH53nCgeyHIrJb+ixQSXrB88R2YdU7qfTnKwuE1Kvzk2IvvrC4tCnzK 9OPck7bMRg8ckwROBrHULp/qrNp31jJtfHAJAlQkkm31UFV7KNVVrvb2BsJhBOarq4w4 e4CA== X-Gm-Message-State: AOAM532UMF+6sA7grs4+4/JpymRic+J9s6JwORCvFGqq/kLF03kPmi3x kDwq6pwGenhD6yEogER66NEC4dQQnyRiIoLJd1g= X-Google-Smtp-Source: ABdhPJwbDWNRt8y3agj8pVgxa+U8NWmkv1TOGxc+ov+d4/hfsglDO0btg6RSZR5w3hSiio0GNxERfuF8vhZCJU9TDOE= X-Received: by 2002:a54:4701:: with SMTP id k1mr3577408oik.175.1589989605509; Wed, 20 May 2020 08:46:45 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> In-Reply-To: <83a7227hkb.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 20 May 2020 12:46:32 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000a212dc05a6164d55" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --000000000000a212dc05a6164d55 Content-Type: text/plain; charset="UTF-8" > Can you explain what problem this solves, and how? It is especially > important to understand when will be emacs_root_dir first called > during a session. That's because it calls filename_from_ansi, which > AFAIR needs some setup that happens at the beginning of a session. When loading a dump file that contains native compiled elisp we try to find the .eln file. This uses Ffile_exists_p(). This function, in turn, calls Fexpand_file_name(). This function will use the root directory as `default_directory' as a fallback. Getting the root directory requires reading the $emacs_dir environment variable. This is setup later in the initialization process. This caused a crash. Fexpand_file_name() was trying to obtain the root directory even when it was not necessary because `default-directory' was not nil. My patch makes sure that this only happens when necessary. It turns out that the dump loading process does not set `default-directory' to nil, therefore Fexpand_file_name() does not need to find out the root directory and we avoid reading an environment variable that is not set yet. With this patch we avoid calling filename_from_ansi() too early (It is not the reason why Emacs crashed, but it is still a good idea to call it after it has been setup properly. Nico --000000000000a212dc05a6164d55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Can you explain what problem this solves, and how?=C2= =A0 It is especially
> important to understand when will be emacs_roo= t_dir first called
> during a session.=C2=A0 That's because it ca= lls filename_from_ansi, which
> AFAIR needs some setup that happens a= t the beginning of a session.

When loading a dump file that contains= native compiled elisp we try to find the
.eln file. This uses Ffile_exi= sts_p(). This function, in turn, calls
Fexpand_file_name(). This functio= n will use the root directory as
`default_directory' as a fallback.<= br>
Getting the root directory requires reading the $emacs_dir environme= nt variable.
This is setup later in the initialization process. This cau= sed a crash.

Fexpand_file_name() was trying to obtain the root direc= tory even when it was not
necessary because `default-directory' was = not nil. My patch makes sure that this
only happens when necessary.
<= br>It turns out that the dump loading process does not set `default-directo= ry' to
nil, therefore Fexpand_file_name() does not need to find out = the root directory
and we avoid reading an environment variable that is = not set yet.

With this patch we avoid calling filename_from_ansi() t= oo early (It is not the
reason why Emacs crashed, but it is still a good= idea to call it after it has
been setup properly.

Nico
--000000000000a212dc05a6164d55-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 11:55:48 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 15:55:48 +0000 Received: from localhost ([127.0.0.1]:54071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbR49-00053M-Fy for submit@debbugs.gnu.org; Wed, 20 May 2020 11:55:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbR47-000538-5d for 41242@debbugs.gnu.org; Wed, 20 May 2020 11:55:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51737) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbR41-0001bO-D8; Wed, 20 May 2020 11:55:25 -0400 Received: from [176.228.60.248] (port=3761 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jbR3u-0002eN-0B; Wed, 20 May 2020 11:55:20 -0400 Date: Wed, 20 May 2020 18:55:17 +0300 Message-Id: <838shm7g9m.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Tue, 19 May 2020 16:23:06 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (-) > From: Nicolas Bértolo > Date: Tue, 19 May 2020 16:23:06 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > I have written the attached patch to handle the deletion > of native compilation units still in use. I have tested that it works well. Thanks. I question the wisdom of handling the deletion from Lisp: if this is specific to MS-Windows, then doing this from C would allow us finer control on what happens. But this can be tackled later if needed, so I'm not going to object to your code. Your legal paperwork is done, so these changes can be installed on the branch. Andrea, please review the changes, and feel free to push at your discretion. From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 12:06:50 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 16:06:50 +0000 Received: from localhost ([127.0.0.1]:54084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRF4-0007Uf-Jb for submit@debbugs.gnu.org; Wed, 20 May 2020 12:06:50 -0400 Received: from mx.sdf.org ([205.166.94.20]:57598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRF2-0007UW-TI for 41242@debbugs.gnu.org; Wed, 20 May 2020 12:06:49 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KG6k79011042 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 16:06:46 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KG6k9L028647; Wed, 20 May 2020 16:06:46 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> Date: Wed, 20 May 2020 16:06:46 +0000 In-Reply-To: <83a7227hkb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 May 2020 18:27:16 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: >> From: Nicolas B=C3=A9rtolo >> Date: Tue, 19 May 2020 16:25:53 -0300 >> Cc: Andrea Corallo , 41242@debbugs.gnu.org >>=20 >> * lisp/emacs-lisp/comp.el (comp-effective-async-max-jobs): Use >> NUMBER_OF_PROCESSORS environment variable if system is Windows NT, >> "nproc" if it is in PATH or a default of 1. > > This shouldn't be necessary: we already have a function to determine > the number of processors, see get_native_system_info in w32.c. If you > need the result exported to Lisp, we can define a new variable which > will be populated with the value. > >> Subject: [PATCH] Determine the emacs root dir only when necessary. >>=20 >> * src/fileio.c: Introduce function emacs_root_dir(). Refactor >> `expand-file-name` to use it. >> * src/lisp.h: Separate emacs_root_dir() into dos_emacs_root_dir() and >> w32_emacs_root_dir(). >> * src/msdos.c: Rename emacs_root_dir() to dos_emacs_root_dir(). >> * src/w32.c: Rename emacs_root_dir() to w32_emacs_root_dir(). > > Can you explain what problem this solves, and how? It is especially > important to understand when will be emacs_root_dir first called > during a session. That's because it calls filename_from_ansi, which > AFAIR needs some setup that happens at the beginning of a session. I'm not into what is happening on Windows and why is working differently than Posix, but I can add this as a context: While we are restarting from dump to reload the native compilation unit in dump_do_dump_relocation we are calling Ffile_exists_p (pdumper.c:5307) and this is calling Fexpand_file_name. We need to do that because we need the eln file to revive the compilation unit object. Perhaps another way would be to use something alternative to Ffile_exists_p? But I've a question: is this a problem of Fexpand_file_name not working correctly because something not initialized or a behavior we are trying to change? Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 12:13:06 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 16:13:06 +0000 Received: from localhost ([127.0.0.1]:54097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRL0-0007eI-Gy for submit@debbugs.gnu.org; Wed, 20 May 2020 12:13:06 -0400 Received: from mx.sdf.org ([205.166.94.20]:56368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRKx-0007e8-A5 for 41242@debbugs.gnu.org; Wed, 20 May 2020 12:12:57 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KGCs20020803 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 16:12:54 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KGCrPi000496; Wed, 20 May 2020 16:12:53 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Wed, 20 May 2020 16:12:53 +0000 In-Reply-To: <838shm7g9m.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 May 2020 18:55:17 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: > Your legal paperwork is done, so these changes can be installed on the > branch. Andrea, please review the changes, and feel free to push at > your discretion. Thanks, I'll start going through them this evening I guess in patch chronological order. Andrea PS Nicolas if some patch is not up to date feel free to post the latest version (or link to a public git repo if you prefer and have one). -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 12:18:15 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 16:18:15 +0000 Received: from localhost ([127.0.0.1]:54105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRQ7-0007nJ-9M for submit@debbugs.gnu.org; Wed, 20 May 2020 12:18:15 -0400 Received: from mail-oo1-f54.google.com ([209.85.161.54]:35179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRQ5-0007n6-NY for 41242@debbugs.gnu.org; Wed, 20 May 2020 12:18:13 -0400 Received: by mail-oo1-f54.google.com with SMTP id c187so849352ooc.2 for <41242@debbugs.gnu.org>; Wed, 20 May 2020 09:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l9znuI+B2yhA/vry2BK2VfsDYFRKr+Aw/PuHh1kzWCA=; b=BFIIjIwTyXQu4xjl9Ozfco6kWWYN51SZ1sLlUGdPKjg3EC166XIjNiYx10dJW+Nb8B JAdVrhMiAyZUpyAlLpiPApprZAmciHhh/Fwy46d3NDlGTXYWDn74cpGb47KPZbumzlGk C37G5kdeFEVeSTWIvL2BPTDjh+yPK4yjIfXWKT8ooXoX1M15r6UusuLdoURoz7LYRQ1y JKTURaMdrycKnTxrOMMP1fXANP8U6GQSytSVz9AELVoNi7eQXjjdPhtQva/DCQTVKTMv U6tc5ksOv2+JaVSiMrjclwS17jVqRSCIg/ZOmhxihTJb2xe5NcnMqbe3TZfZlae5t4sI TBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l9znuI+B2yhA/vry2BK2VfsDYFRKr+Aw/PuHh1kzWCA=; b=nONx3/kFYKZym3WOANJi0Mg7QgV/uzr6XAWFRKAIGBBt541nsLZQACrZr/6njkQ5u5 DZJiL8/Nj30zikJ5V3W71lOY6UKZSidaVKN2dJArrlu8WG55h6vDeMm9gzHxiWpQLycU L8RQFLMYxFRCbY/SvxLUE0KRVHbErRQdsSw9pjJa3qKe5Shg17+x7BYuFaBeztKpT4Z4 6c08pxk6SRxSNczYn05a8yYNRZLIDvGJtUHzn5meuTwavpTIENRnEcDx2PljoF+So3ji v4i2tZa+Ps2y7XxRCIG15NLnEyJaLd3lQ2V6USjFbhhNRI7zTFwxn5wHVeD8f63km8P1 lLMg== X-Gm-Message-State: AOAM531fggabKFQ3hip7eVOao3gGbJRji+B6m+Q3347cUUrWEyIuWORN A+ogln6im/2Or6aImlK55qQ0eXCsBzey5ywApc8= X-Google-Smtp-Source: ABdhPJx5xW7vptc7nqy7BbhWY61a22U4qqMOwII8beTaAGTcUjgvcJMP4wJW+AX50cmmQ3+Bmmu1uxWgZgZV1ysn0p4= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr3958680oon.22.1589991488052; Wed, 20 May 2020 09:18:08 -0700 (PDT) MIME-Version: 1.0 References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 20 May 2020 13:17:54 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000d7b75005a616bdaa" X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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" --000000000000d7b75005a616bdaa Content-Type: multipart/alternative; boundary="000000000000d7b74d05a616bda8" --000000000000d7b74d05a616bda8 Content-Type: text/plain; charset="UTF-8" > Thanks, I'll start going through them this evening I guess in patch > chronological order. Thank you. Here's the latest version. --000000000000d7b74d05a616bda8 Content-Type: text/html; charset="UTF-8"
> Thanks, I'll start going through them this evening I guess in patch
> chronological order.

Thank you.

Here's the latest version.
--000000000000d7b74d05a616bda8-- --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0003-Handle-setjmp-taking-two-arguments-in-Windows.patch" Content-Disposition: attachment; filename="0003-Handle-setjmp-taking-two-arguments-in-Windows.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5u22 RnJvbSBiZWNmOTRiMzUyYTZjNjQ2ZDcwM2VhYTA1N2IwODcwZTZmZGE2NTMyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE1OjU2 OjA5IC0wMzAwClN1YmplY3Q6IFtQQVRDSCAzLzldIEhhbmRsZSBzZXRqbXAoKSB0YWtpbmcgdHdv IGFyZ3VtZW50cyBpbiBXaW5kb3dzLgoKKiBzcmMvY29tcC5jOiBBZGQgYGRlZmluZV9zZXRqbXBf ZGVwcygpYCBhbmQgYGVtaXRfc2V0am1wKClgIHdoaWNoCmFic3RyYWN0IG92ZXIgdGhpcyBkaWZm ZXJlbmNlIGluIGJlaGF2aW9yIGJldHdlZW4gb3BlcmF0aW5nIHN5c3RlbXMuCgpXQVJOSU5HOiBO b3QgYWxsIGNhc2VzIGFyZSBoYW5kbGVkIGJ5IHRoaXMgcGF0Y2guIFRoZSBNaW5ndy02NApzZXRq bXAuaCBoZWFkZXIgZGVhbHMgd2l0aCBtYW55IG90aGVyIGNvbWJpbmF0aW9ucy4gSSBkb24ndCB0 aGluayBpdAppcyBhIGdvb2QgaWRlYSB0byByZXBsaWNhdGUgdGhlIGxvZ2ljIG9mIHRoYXQgaGVh ZGVyIGluc2lkZQplbWFjcy4gKE1heWJlIGEgZmV3IGxpbmVzIGluIHRoZSBjb25maWd1cmUgc2Ny aXB0IGNvdWxkIGJlIGFkZGVkIHRvCmhhbmRsZSB0aGlzIHByb2JsZW0/KQotLS0KIHNyYy9jb21w LmMgfCA1OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKyst LS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA1MiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoK ZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29tcC5jCmluZGV4IDAwZjlkNGI3NGEuLjBk NDY2MjhlNmEgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMKKysrIGIvc3JjL2NvbXAuYwpAQCAtMjIs NiArMjIsNyBAQAogCiAjaWZkZWYgSEFWRV9OQVRJVkVfQ09NUAogCisjaW5jbHVkZSA8c2V0am1w Lmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxz aWduYWwuaD4KQEAgLTc0LDEwICs3NSwxNSBAQCAjZGVmaW5lIERFQ0xfQkxPQ0sobmFtZSwgZnVu YykJCQkJXAogICBnY2Nfaml0X2Jsb2NrICoobmFtZSkgPQkJCQlcCiAgICAgZ2NjX2ppdF9mdW5j dGlvbl9uZXdfYmxvY2sgKChmdW5jKSwgU1RSIChuYW1lKSkKIAotI2lmZGVmIEhBVkVfX1NFVEpN UAotI2RlZmluZSBTRVRKTVAgX3NldGptcAorI2lmbmRlZiBfV0lOMzIKKyMgaWZkZWYgSEFWRV9f U0VUSk1QCisjICBkZWZpbmUgU0VUSk1QIF9zZXRqbXAKKyMgZWxzZQorIyAgZGVmaW5lIFNFVEpN UCBzZXRqbXAKKyMgZW5kaWYKICNlbHNlCi0jZGVmaW5lIFNFVEpNUCBzZXRqbXAKKy8qIHNuaXBw ZXQgZnJvbSBNSU5HVy02NCBzZXRqbXAuaCAqLworIyBkZWZpbmUgU0VUSk1QIF9zZXRqbXAKICNl bmRpZgogI2RlZmluZSBTRVRKTVBfTkFNRSBTRVRKTVAKIApAQCAtMTc0LDYgKzE4MCw5IEBAICNk ZWZpbmUgRl9SRUxPQ19NQVhfU0laRSAxNTAwCiAgIGdjY19qaXRfZnVuY3Rpb24gKnNldGNkcjsK ICAgZ2NjX2ppdF9mdW5jdGlvbiAqY2hlY2tfdHlwZTsKICAgZ2NjX2ppdF9mdW5jdGlvbiAqY2hl Y2tfaW1wdXJlOworI2lmZGVmIF9XSU4zMgorICBnY2Nfaml0X2Z1bmN0aW9uICpzZXRqbXBfY3R4 X2Z1bmM7CisjZW5kaWYKICAgTGlzcF9PYmplY3QgZnVuY19ibG9ja3NfaDsgLyogYmxrX25hbWUg LT4gZ2NjX2Jsb2NrLiAgKi8KICAgTGlzcF9PYmplY3QgZXhwb3J0ZWRfZnVuY3NfaDsgLyogYy1m dW5jLW5hbWUgLT4gZ2NjX2ppdF9mdW5jdGlvbiAqLiAgKi8KICAgTGlzcF9PYmplY3QgaW1wb3J0 ZWRfZnVuY3NfaDsgLyogc3Vicl9uYW1lIC0+IGdjY19qaXRfZmllbGQgKnJlbG9jX2ZpZWxkLiAg Ki8KQEAgLTE0NzQsNiArMTQ4MywyOSBAQCBlbWl0X2xpbXBsZV9jYWxsX3JlZiAoTGlzcF9PYmpl Y3QgaW5zbiwgYm9vbCBkaXJlY3QpCiAJCQlkaXJlY3QpOwogfQogCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9zZXRqbXAgKGdjY19qaXRfcnZhbHVlICpidWYpCit7CisjaWZuZGVmIF9X SU4zMgorICBnY2Nfaml0X3J2YWx1ZSAqYXJnc1tdID0ge2J1Zn07CisgIHJldHVybiBlbWl0X2Nh bGwgKGludGVybl9jX3N0cmluZyAoU1RSIChTRVRKTVBfTkFNRSkpLCBjb21wLmludF90eXBlLCAx LCBhcmdzLAorICAgICAgICAgICAgICAgICAgIGZhbHNlKTsKKyNlbHNlCisgIC8qIF9zZXRqbXAg KGJ1ZiwgX19idWlsdGluX2ZyYW1lX2FkZHJlc3MgKDApKSAqLworICBnY2Nfaml0X3J2YWx1ZSAq YXJnc1syXTsKKworICBhcmdzWzBdID0gZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9p bnQgKGNvbXAuY3R4dCwgY29tcC51bnNpZ25lZF90eXBlLCAwKTsKKworICBhcmdzWzFdID0gZ2Nj X2ppdF9jb250ZXh0X25ld19jYWxsKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbXAuc2V0am1wX2N0eF9mdW5jLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDEsIGFyZ3MpOworICBhcmdzWzBdID0gYnVmOworICByZXR1cm4gZW1pdF9jYWxsIChpbnRl cm5fY19zdHJpbmcgKFNUUiAoU0VUSk1QX05BTUUpKSwgY29tcC5pbnRfdHlwZSwgMiwgYXJncywK KyAgICAgICAgICAgICAgICAgICAgZmFsc2UpOworI2VuZGlmCit9CisKIC8qIFJlZ2lzdGVyIGFu IGhhbmRsZXIgZm9yIGEgbm9uIGxvY2FsIGV4aXQuICAqLwogCiBzdGF0aWMgdm9pZApAQCAtMTUw MCw4ICsxNTMyLDcgQEAgZW1pdF9saW1wbGVfcHVzaF9oYW5kbGVyIChnY2Nfaml0X3J2YWx1ZSAq aGFuZGxlciwgZ2NjX2ppdF9ydmFsdWUgKmhhbmRsZXJfdHlwZSwKIAlOVUxMKTsKIAogICBnY2Nf aml0X3J2YWx1ZSAqcmVzOwotICByZXMgPQotICAgIGVtaXRfY2FsbCAoaW50ZXJuX2Nfc3RyaW5n IChTVFIgKFNFVEpNUF9OQU1FKSksIGNvbXAuaW50X3R5cGUsIDEsIGFyZ3MsIGZhbHNlKTsKKyAg cmVzID0gZW1pdF9zZXRqbXAoYXJnc1swXSk7CiAgIGVtaXRfY29uZF9qdW1wIChyZXMsIGhhbmRs ZXJfYmIsIGd1YXJkZWRfYmIpOwogfQogCkBAIC0yMDYwLDggKzIwOTEsMTQgQEAgI2RlZmluZSBB RERfSU1QT1JURUQoZl9uYW1lLCByZXRfdHlwZSwgbmFyZ3MsIGFyZ3MpCQkJICAgICAgIFwKICAg YXJnc1sxXSA9IGNvbXAuaW50X3R5cGU7CiAgIEFERF9JTVBPUlRFRCAocHVzaF9oYW5kbGVyLCBj b21wLmhhbmRsZXJfcHRyX3R5cGUsIDIsIGFyZ3MpOwogCisjaWZuZGVmIF9XSU4zMgogICBhcmdz WzBdID0gZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyIChnY2Nfaml0X3N0cnVjdF9hc190eXBlIChj b21wLmptcF9idWZfcykpOwogICBBRERfSU1QT1JURUQgKFNFVEpNUF9OQU1FLCBjb21wLmludF90 eXBlLCAxLCBhcmdzKTsKKyNlbHNlCisgIGFyZ3NbMF0gPSBnY2Nfaml0X3R5cGVfZ2V0X3BvaW50 ZXIgKGdjY19qaXRfc3RydWN0X2FzX3R5cGUgKGNvbXAuam1wX2J1Zl9zKSk7CisgIGFyZ3NbMV0g PSBjb21wLnZvaWRfcHRyX3R5cGU7CisgIEFERF9JTVBPUlRFRCAoU0VUSk1QX05BTUUsIGNvbXAu aW50X3R5cGUsIDIsIGFyZ3MpOworI2VuZGlmCiAKICAgQUREX0lNUE9SVEVEIChyZWNvcmRfdW53 aW5kX3Byb3RlY3RfZXhjdXJzaW9uLCBjb21wLnZvaWRfdHlwZSwgMCwgTlVMTCk7CiAKQEAgLTIz MDEsNyArMjMzOCw3IEBAIGRlZmluZV9qbXBfYnVmICh2b2lkKQogICAgICAgZ2NjX2ppdF9jb250 ZXh0X25ld19hcnJheV90eXBlIChjb21wLmN0eHQsCiAJCQkJICAgICAgTlVMTCwKIAkJCQkgICAg ICBjb21wLmNoYXJfdHlwZSwKLQkJCQkgICAgICBzaXplb2YgKGptcF9idWYpKSwKKwkJCQkgICAg ICBzaXplb2YgKHN5c19qbXBfYnVmKSksCiAgICAgICAic3R1ZmYiKTsKICAgY29tcC5qbXBfYnVm X3MgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfc3RydWN0X3R5cGUgKGNvbXAuY3R4dCwKQEAg LTI5NjksNiArMzAwNiwxNCBAQCBkZWZpbmVfQ0hFQ0tfSU1QVVJFICh2b2lkKQogICAgIGdjY19q aXRfYmxvY2tfZW5kX3dpdGhfdm9pZF9yZXR1cm4gKGVycl9ibG9jaywgTlVMTCk7CiB9CiAKK3N0 YXRpYyB2b2lkCitkZWZpbmVfc2V0am1wX2RlcHMgKHZvaWQpCit7CisgIGNvbXAuc2V0am1wX2N0 eF9mdW5jCisgICAgPSBnY2Nfaml0X2NvbnRleHRfZ2V0X2J1aWx0aW5fZnVuY3Rpb24gKGNvbXAu Y3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIl9fYnVp bHRpbl9mcmFtZV9hZGRyZXNzIik7Cit9CisKIC8qIERlZmluZSBhIGZ1bmN0aW9uIHRvIGNvbnZl cnQgYm9vbGVhbiBpbnRvIHQgb3IgbmlsICovCiAKIHN0YXRpYyB2b2lkCkBAIC0zMzU3LDYgKzM0 MDIsNyBAQCBERUZVTiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBfX2NvbXBp bGVfY3R4dF90b19maWxlLAogICBkZWZpbmVfUFNFVURPVkVDVE9SUCAoKTsKICAgZGVmaW5lX0NI RUNLX1RZUEUgKCk7CiAgIGRlZmluZV9DSEVDS19JTVBVUkUgKCk7CisgIGRlZmluZV9zZXRqbXBf ZGVwcyAoKTsKICAgZGVmaW5lX2Jvb2xfdG9fbGlzcF9vYmogKCk7CiAgIGRlZmluZV9zZXRjYXJf c2V0Y2RyICgpOwogICBkZWZpbmVfYWRkMV9zdWIxICgpOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch" Content-Disposition: attachment; filename="0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5ur3 RnJvbSA0NGNlMmNiODk4NTY3MDlmYTQ1ODFlZDRlM2I4MDkxYjJkMmMzNTFjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE0OjMw OjE0IC0wMzAwClN1YmplY3Q6IFtQQVRDSCA0LzldIEhhbmRsZSBMSVNQX1dPUkRTX0FSRV9QT0lO VEVSUyBhbmQKIENIRUNLX0xJU1BfT0JKRUNUX1RZUEUuCgoqIHNyYy9jb21wLmM6IEludHJvZHVj ZSB0aGUgTGlzcF9YLCBMaXNwX1dvcmQsIGFuZCBMaXNwX1dvcmRfdGFnCnR5cGVzLiBUaGVzZSB0 eXBlcyBhcmUgdXNlZCBpbnN0ZWFkIG9mIGxvbmcgb3IgbG9uZyBsb25nLiBVc2UKZW1hY3NfaW50 X3R5cGUgYW5kIGVtYWNzX3VpbnRfdHlwZXMgd2hlcmUgYXBwcm9wcmlhdGUuCihlbWl0X2NvZXJj ZSk6IEFkZCBzcGVjaWFsIGxvZ2ljIHRoYXQgaGFuZGxlcyB0aGUgY2FzZSB3aGVuCkxpc3BfT2Jq ZWN0IGlzIGEgc3RydWN0LiBUaGlzIGlzIG5lY2Vzc2FyeSBmb3IgaGFuZGxpbmcgdGhlCi0tZW5h YmxlLWNoZWNrLWxpc3Atb2JqZWN0LXR5cGUgY29uZmlndXJlIG9wdGlvbi4KCiogc3JjL2xpc3Au aDogU2luY2UgbGliZ2Njaml0IGRvZXMgbm90IHN1cHBvcnQgb3BhcXVlIHVuaW9ucywgY2hhbmdl Ckxpc3BfWCB0byBiZSBzdHJ1Y3QuIFRoaXMgaXMgZG9uZSB0byBlbnN1cmUgdGhhdCB0aGUgc2Ft ZSB0eXBlcyBhcmUKdXNlZCBpbiB0aGUgc2FtZSBiaW5hcnkuIEl0IGlzIHByb2JhYmx5IHVubmVj ZXNzYXJ5IHNpbmNlIG9ubHkgYQpwb2ludGVyIHRvIGl0IGlzIHVzZWQuCi0tLQogc3JjL2NvbXAu YyB8IDMyOCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t LS0tLQogc3JjL2xpc3AuaCB8ICAgNSArLQogMiBmaWxlcyBjaGFuZ2VkLCAyMjggaW5zZXJ0aW9u cygrKSwgMTA1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29t cC5jCmluZGV4IDBkNDY2MjhlNmEuLjBkNTg4MGFkM2MgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMK KysrIGIvc3JjL2NvbXAuYwpAQCAtMTE2LDYgKzExNiwxNiBAQCAjZGVmaW5lIEZfUkVMT0NfTUFY X1NJWkUgMTUwMAogICBnY2Nfaml0X3R5cGUgKmNoYXJfcHRyX3R5cGU7CiAgIGdjY19qaXRfdHlw ZSAqcHRyZGlmZl90eXBlOwogICBnY2Nfaml0X3R5cGUgKnVpbnRwdHJfdHlwZTsKKyNpZiBMSVNQ X1dPUkRTX0FSRV9QT0lOVEVSUworICBnY2Nfaml0X3N0cnVjdCAqbGlzcF9YX3M7CisgIGdjY19q aXRfdHlwZSAqbGlzcF9YOworI2VuZGlmCisgIGdjY19qaXRfdHlwZSAqbGlzcF93b3JkX3R5cGU7 CisgIGdjY19qaXRfdHlwZSAqbGlzcF93b3JkX3RhZ190eXBlOworI2lmZGVmIExJU1BfT0JKRUNU X0lTX1NUUlVDVAorICBnY2Nfaml0X2ZpZWxkICpsaXNwX29ial9pOworICBnY2Nfaml0X3N0cnVj dCAqbGlzcF9vYmpfczsKKyNlbmRpZgogICBnY2Nfaml0X3R5cGUgKmxpc3Bfb2JqX3R5cGU7CiAg IGdjY19qaXRfdHlwZSAqbGlzcF9vYmpfcHRyX3R5cGU7CiAgIC8qIHN0cnVjdCBMaXNwX0NvbnMg Ki8KQEAgLTE1OCw3ICsxNjgsOCBAQCAjZGVmaW5lIEZfUkVMT0NfTUFYX1NJWkUgMTUwMAogICBn Y2Nfaml0X2ZpZWxkICpjYXN0X3VuaW9uX2FzX2NfcDsKICAgZ2NjX2ppdF9maWVsZCAqY2FzdF91 bmlvbl9hc192X3A7CiAgIGdjY19qaXRfZmllbGQgKmNhc3RfdW5pb25fYXNfbGlzcF9jb25zX3B0 cjsKLSAgZ2NjX2ppdF9maWVsZCAqY2FzdF91bmlvbl9hc19saXNwX29iajsKKyAgZ2NjX2ppdF9m aWVsZCAqY2FzdF91bmlvbl9hc19saXNwX3dvcmQ7CisgIGdjY19qaXRfZmllbGQgKmNhc3RfdW5p b25fYXNfbGlzcF93b3JkX3RhZzsKICAgZ2NjX2ppdF9maWVsZCAqY2FzdF91bmlvbl9hc19saXNw X29ial9wdHI7CiAgIGdjY19qaXRfZnVuY3Rpb24gKmZ1bmM7IC8qIEN1cnJlbnQgZnVuY3Rpb24g YmVpbmcgY29tcGlsZWQuICAqLwogICBib29sIGZ1bmNfaGFzX25vbl9sb2NhbDsgLyogRnJvbSBj b21wLWZ1bmMgaGFzLW5vbi1sb2NhbCBzbG90LiAgKi8KQEAgLTM0Nyw4ICszNTgsMTAgQEAgdHlw ZV90b19jYXN0X2ZpZWxkIChnY2Nfaml0X3R5cGUgKnR5cGUpCiAgICAgZmllbGQgPSBjb21wLmNh c3RfdW5pb25fYXNfY19wOwogICBlbHNlIGlmICh0eXBlID09IGNvbXAubGlzcF9jb25zX3B0cl90 eXBlKQogICAgIGZpZWxkID0gY29tcC5jYXN0X3VuaW9uX2FzX2xpc3BfY29uc19wdHI7Ci0gIGVs c2UgaWYgKHR5cGUgPT0gY29tcC5saXNwX29ial90eXBlKQotICAgIGZpZWxkID0gY29tcC5jYXN0 X3VuaW9uX2FzX2xpc3Bfb2JqOworICBlbHNlIGlmICh0eXBlID09IGNvbXAubGlzcF93b3JkX3R5 cGUpCisgICAgZmllbGQgPSBjb21wLmNhc3RfdW5pb25fYXNfbGlzcF93b3JkOworICBlbHNlIGlm ICh0eXBlID09IGNvbXAubGlzcF93b3JkX3RhZ190eXBlKQorICAgIGZpZWxkID0gY29tcC5jYXN0 X3VuaW9uX2FzX2xpc3Bfd29yZF90YWc7CiAgIGVsc2UgaWYgKHR5cGUgPT0gY29tcC5saXNwX29i al9wdHJfdHlwZSkKICAgICBmaWVsZCA9IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29ial9wdHI7 CiAgIGVsc2UKQEAgLTYyNyw2ICs2NDAsMzEgQEAgZW1pdF9jb2VyY2UgKGdjY19qaXRfdHlwZSAq bmV3X3R5cGUsIGdjY19qaXRfcnZhbHVlICpvYmopCiAgIGlmIChuZXdfdHlwZSA9PSBvbGRfdHlw ZSkKICAgICByZXR1cm4gb2JqOwogCisjaWZkZWYgTElTUF9PQkpFQ1RfSVNfU1RSVUNUCisgIGlm IChvbGRfdHlwZSA9PSBjb21wLmxpc3Bfb2JqX3R5cGUpCisgICAgeworICAgICAgZ2NjX2ppdF9y dmFsdWUgKmx3b3Jkb2JqID0KKyAgICAgICAgZ2NjX2ppdF9ydmFsdWVfYWNjZXNzX2ZpZWxkIChv YmosIE5VTEwsIGNvbXAubGlzcF9vYmpfaSk7CisgICAgICByZXR1cm4gZW1pdF9jb2VyY2UgKG5l d190eXBlLCBsd29yZG9iaik7CisgICAgfQorCisgIGlmIChuZXdfdHlwZSA9PSBjb21wLmxpc3Bf b2JqX3R5cGUpCisgICAgeworICAgICAgZ2NjX2ppdF9ydmFsdWUgKmx3b3Jkb2JqID0KKyAgICAg ICAgZW1pdF9jb2VyY2UgKGNvbXAubGlzcF93b3JkX3R5cGUsIG9iaik7CisKKyAgICAgIGdjY19q aXRfbHZhbHVlICp0bXBfcworICAgICAgICA9IGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsIChj b21wLmZ1bmMsIE5VTEwsIGNvbXAubGlzcF9vYmpfdHlwZSwKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9ybWF0X3N0cmluZyAoImxpc3Bfb2JqXyV0ZCIsIGkrKykpOwor CisgICAgICBnY2Nfaml0X2Jsb2NrX2FkZF9hc3NpZ25tZW50IChjb21wLmJsb2NrLCBOVUxMLAor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2NjX2ppdF9sdmFsdWVfYWNjZXNz X2ZpZWxkICh0bXBfcywgTlVMTCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX29ial9pKSwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGx3b3Jkb2JqKTsKKyAgICAgIHJldHVybiBnY2Nf aml0X2x2YWx1ZV9hc19ydmFsdWUgKHRtcF9zKTsKKyAgICB9CisjZW5kaWYKKwogICBnY2Nfaml0 X2ZpZWxkICpvcmlnX2ZpZWxkID0KICAgICB0eXBlX3RvX2Nhc3RfZmllbGQgKG9sZF90eXBlKTsK ICAgZ2NjX2ppdF9maWVsZCAqZGVzdF9maWVsZCA9IHR5cGVfdG9fY2FzdF9maWVsZCAobmV3X3R5 cGUpOwpAQCAtNjY0LDE0ICs3MDIsOCBAQCBlbWl0X2JpbmFyeV9vcCAoZW51bSBnY2Nfaml0X2Jp bmFyeV9vcCBvcCwKIC8qIFNob3VsZCBjb21lIHdpdGggbGliZ2Njaml0LiAgKi8KIAogc3RhdGlj IGdjY19qaXRfcnZhbHVlICoKLWVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChsb25nIGxvbmcg bikKK2VtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChnY2Nfaml0X3R5cGUgKnR5cGUsIGxvbmcg bG9uZyBuKQogewotI2lmbmRlZiBXSURFX0VNQUNTX0lOVAotICB4c2lnbmFsMSAoUW5hdGl2ZV9p Y2UsCi0JICAgIGJ1aWxkX3N0cmluZyAoImVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIGNhbGxl ZCBpbiBub24gd2lkZSBpbnQiCi0JCQkgICIgY29uZmlndXJhdGlvbiIpKTsKLSNlbmRpZgotCiAg IGVtaXRfY29tbWVudCAoZm9ybWF0X3N0cmluZyAoImVtaXQgbG9uZyBsb25nOiAlbGxkIiwgbikp OwogCiAgIGdjY19qaXRfcnZhbHVlICpoaWdoID0KQEAgLTY5Nyw3ICs3MjksNyBAQCBlbWl0X3J2 YWx1ZV9mcm9tX2xvbmdfbG9uZyAobG9uZyBsb25nIG4pCiAJCSAgICAgIDMyKSk7CiAKICAgcmV0 dXJuCi0gICAgZW1pdF9jb2VyY2UgKGNvbXAubG9uZ19sb25nX3R5cGUsCisgICAgZW1pdF9jb2Vy Y2UgKHR5cGUsCiAgICAgICBlbWl0X2JpbmFyeV9vcCAoCiAJR0NDX0pJVF9CSU5BUllfT1BfQklU V0lTRV9PUiwKIAljb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLApAQCAtNzEyLDI5ICs3NDQs MTM1IEBAIGVtaXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChsb25nIGxvbmcgbikKIH0KIAogc3Rh dGljIGdjY19qaXRfcnZhbHVlICoKLWVtaXRfbW9zdF9wb3NpdGl2ZV9maXhudW0gKHZvaWQpCitl bWl0X3J2YWx1ZV9mcm9tX3Vuc2lnbmVkX2xvbmdfbG9uZyAoZ2NjX2ppdF90eXBlICp0eXBlLCB1 bnNpZ25lZCBsb25nIGxvbmcgbikKK3sKKyAgZW1pdF9jb21tZW50IChmb3JtYXRfc3RyaW5nICgi ZW1pdCB1bnNpZ25lZCBsb25nIGxvbmc6ICVsbHUiLCBuKSk7CisKKyAgZ2NjX2ppdF9ydmFsdWUg KmhpZ2ggPQorICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9uZyAoY29tcC5j dHh0LAorCQkJCQkgIGNvbXAudW5zaWduZWRfbG9uZ19sb25nX3R5cGUsCisJCQkJCSAgbiA+PiAz Mik7CisgIGdjY19qaXRfcnZhbHVlICpsb3cgPQorICAgIGVtaXRfYmluYXJ5X29wIChHQ0NfSklU X0JJTkFSWV9PUF9SU0hJRlQsCisJCSAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAor CQkgICAgZW1pdF9iaW5hcnlfb3AgKEdDQ19KSVRfQklOQVJZX09QX0xTSElGVCwKKwkJCQkgICAg Y29tcC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJCQkgICAgZ2NjX2ppdF9jb250ZXh0X25l d19ydmFsdWVfZnJvbV9sb25nICgKKwkJCQkgICAgICBjb21wLmN0eHQsCisJCQkJICAgICAgY29t cC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJCQkgICAgICBuKSwKKwkJCQkgICAgZ2NjX2pp dF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKAorCQkJCSAgICAgIGNvbXAuY3R4dCwKKwkJ CQkgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorCQkJCSAgICAgIDMyKSksCisJ CSAgICBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCAoCisJCSAgICAgIGNvbXAu Y3R4dCwKKwkJICAgICAgY29tcC51bnNpZ25lZF9sb25nX2xvbmdfdHlwZSwKKwkJICAgICAgMzIp KTsKKworICByZXR1cm4gZW1pdF9jb2VyY2UgKAorICAgICAgICAgICB0eXBlLAorICAgICAgICAg ICBlbWl0X2JpbmFyeV9vcCAoCisgICAgICAgICAgICAgR0NDX0pJVF9CSU5BUllfT1BfQklUV0lT RV9PUiwKKyAgICAgICAgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorICAgICAg ICAgICAgIGVtaXRfYmluYXJ5X29wICgKKyAgICAgICAgICAgICAgIEdDQ19KSVRfQklOQVJZX09Q X0xTSElGVCwKKyAgICAgICAgICAgICAgIGNvbXAudW5zaWduZWRfbG9uZ19sb25nX3R5cGUsCisg ICAgICAgICAgICAgICBoaWdoLAorICAgICAgICAgICAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19y dmFsdWVfZnJvbV9pbnQgKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190eXBlLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMyKSksCisg ICAgICAgICAgICAgbG93KSk7Cit9CisKK3N0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCitlbWl0X3J2 YWx1ZV9mcm9tX2VtYWNzX3VpbnQgKEVNQUNTX1VJTlQgdmFsKQoreworICBpZiAodmFsICE9IChs b25nKSB2YWwpCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVl X2Zyb21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29tcC5lbWFjc191aW50X3R5cGUsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWwpOworICAgIH0KKyAgZWxzZQor ICAgIHsKKyAgICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX3Vuc2lnbmVkX2xvbmdfbG9uZyAo Y29tcC5lbWFjc191aW50X3R5cGUsIHZhbCk7CisgICAgfQorfQorCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9ydmFsdWVfZnJvbV9lbWFjc19pbnQgKEVNQUNTX0lOVCB2YWwpCit7Cisg IGlmICh2YWwgIT0gKGxvbmcpIHZhbCkKKyAgICB7CisgICAgICByZXR1cm4gZW1pdF9ydmFsdWVf ZnJvbV9sb25nX2xvbmcgKGNvbXAuZW1hY3NfaW50X3R5cGUsIHZhbCk7CisgICAgfQorICBlbHNl CisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9u ZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29tcC5lbWFjc19pbnRfdHlwZSwgdmFsKTsKKyAgICB9Cit9CisKK3N0YXRpYyBn Y2Nfaml0X3J2YWx1ZSAqCitlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfd29yZF90YWcgKExpc3BfV29y ZF90YWcgdmFsKQogewotI2lmIEVNQUNTX0lOVF9NQVggPiBMT05HX01BWAotICByZXR1cm4gZW1p dF9ydmFsdWVfZnJvbV9sb25nX2xvbmcgKE1PU1RfUE9TSVRJVkVfRklYTlVNKTsKKyAgaWYgKHZh bCAhPSAobG9uZykgdmFsKQorICAgIHsKKyAgICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX3Vu c2lnbmVkX2xvbmdfbG9uZyAoY29tcC5saXNwX3dvcmRfdGFnX3R5cGUsIHZhbCk7CisgICAgfQor ICBlbHNlCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zy b21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdGFnX3R5cGUsCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWwpOworICAgIH0KK30KKworc3Rh dGljIGdjY19qaXRfcnZhbHVlICoKK2VtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkIChMaXNwX1dv cmQgdmFsKQoreworI2lmIExJU1BfV09SRFNfQVJFX1BPSU5URVJTCisgIHJldHVybiBnY2Nfaml0 X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX3B0ciAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXAubGlzcF93b3JkX3R5cGUsCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsKICNlbHNlCi0g IHJldHVybiBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcgKGNvbXAuY3R4dCwK LQkJCQkJICAgICAgIGNvbXAuZW1hY3NfaW50X3R5cGUsCi0JCQkJCSAgICAgICBNT1NUX1BPU0lU SVZFX0ZJWE5VTSk7CisgIGlmICh2YWwgIT0gKGxvbmcpIHZhbCkKKyAgICB7CisgICAgICByZXR1 cm4gZW1pdF9ydmFsdWVfZnJvbV91bnNpZ25lZF9sb25nX2xvbmcgKGNvbXAubGlzcF93b3JkX3R5 cGUsIHZhbCk7CisgICAgfQorICBlbHNlCisgICAgeworICAgICAgcmV0dXJuIGdjY19qaXRfY29u dGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9uZyAoY29tcC5jdHh0LAorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdHlwZSwKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhbCk7Cisg ICAgfQogI2VuZGlmCiB9CiAKIHN0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCi1lbWl0X21vc3RfbmVn YXRpdmVfZml4bnVtICh2b2lkKQorZW1pdF9ydmFsdWVfZnJvbV9saXNwX29iaiAoTGlzcF9PYmpl Y3Qgb2JqKQogewotI2lmIEVNQUNTX0lOVF9NQVggPiBMT05HX01BWAotICByZXR1cm4gZW1pdF9y dmFsdWVfZnJvbV9sb25nX2xvbmcgKE1PU1RfTkVHQVRJVkVfRklYTlVNKTsKKyNpZmRlZiBMSVNQ X09CSkVDVF9JU19TVFJVQ1QKKyAgcmV0dXJuIGVtaXRfY29lcmNlKGNvbXAubGlzcF9vYmpfdHlw ZSwKKyAgICAgICAgICAgICAgICAgICAgIGVtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkIChvYmou aSkpOwogI2Vsc2UKLSAgcmV0dXJuIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fbG9u ZyAoY29tcC5jdHh0LAotCQkJCQkgICAgICAgY29tcC5lbWFjc19pbnRfdHlwZSwKLQkJCQkJICAg ICAgIE1PU1RfTkVHQVRJVkVfRklYTlVNKTsKKyAgcmV0dXJuIGVtaXRfcnZhbHVlX2Zyb21fbGlz cF93b3JkIChvYmopOwogI2VuZGlmCiB9CiAKK3N0YXRpYyBnY2Nfaml0X3J2YWx1ZSAqCitlbWl0 X21vc3RfcG9zaXRpdmVfZml4bnVtICh2b2lkKQoreworICByZXR1cm4gZW1pdF9ydmFsdWVfZnJv bV9lbWFjc19pbnQoTU9TVF9QT1NJVElWRV9GSVhOVU0pOworfQorCitzdGF0aWMgZ2NjX2ppdF9y dmFsdWUgKgorZW1pdF9tb3N0X25lZ2F0aXZlX2ZpeG51bSAodm9pZCkKK3sKKyAgcmV0dXJuIGVt aXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX05FR0FUSVZFX0ZJWE5VTSk7Cit9CisKIC8q CiAgICBFbWl0IHRoZSBlcXVpdmFsZW50IG9mOgogICAgKHR5cGVvZl9wdHIpICgodWludHB0cikg cHRyICsgc2l6ZV9vZl9wdHJfcmVmICogaSkKQEAgLTc2OSw3ICs5MDcsNyBAQCBlbWl0X3B0cl9h cml0aG1ldGljIChnY2Nfaml0X3J2YWx1ZSAqcHRyLCBnY2Nfaml0X3R5cGUgKnB0cl90eXBlLAog ZW1pdF9YTEkgKGdjY19qaXRfcnZhbHVlICpvYmopCiB7CiAgIGVtaXRfY29tbWVudCAoIlhMSSIp OwotICByZXR1cm4gb2JqOworICByZXR1cm4gZW1pdF9jb2VyY2UgKGNvbXAuZW1hY3NfaW50X3R5 cGUsIG9iaik7CiB9CiAKIHN0YXRpYyBnY2Nfaml0X2x2YWx1ZSAqCkBAIC03NzksNTQgKzkxNyw0 MCBAQCBlbWl0X2x2YWxfWExJIChnY2Nfaml0X2x2YWx1ZSAqb2JqKQogICByZXR1cm4gb2JqOwog fQogCi0vKgorCiBzdGF0aWMgZ2NjX2ppdF9ydmFsdWUgKgogZW1pdF9YTFAgKGdjY19qaXRfcnZh bHVlICpvYmopCiB7CiAgIGVtaXRfY29tbWVudCAoIlhMUCIpOwogCi0gIHJldHVybiBnY2Nfaml0 X3J2YWx1ZV9hY2Nlc3NfZmllbGQgKG9iaiwKLQkJCQkgICAgICBOVUxMLAotCQkJCSAgICAgIGNv bXAubGlzcF9vYmpfYXNfcHRyKTsKKyAgcmV0dXJuIGVtaXRfY29lcmNlKGNvbXAudm9pZF9wdHJf dHlwZSwgb2JqKTsKIH0KIAotc3RhdGljIGdjY19qaXRfbHZhbHVlICoKLWVtaXRfbHZhbF9YTFAg KGdjY19qaXRfbHZhbHVlICpvYmopCi17Ci0gIGVtaXRfY29tbWVudCAoImx2YWxfWExQIik7Cisv KiBUT0RPICovCisvKiBzdGF0aWMgZ2NjX2ppdF9sdmFsdWUgKiAqLworLyogZW1pdF9sdmFsX1hM UCAoZ2NjX2ppdF9sdmFsdWUgKm9iaikgKi8KKy8qIHsgKi8KKy8qICAgZW1pdF9jb21tZW50ICgi bHZhbF9YTFAiKTsgKi8KKworLyogICByZXR1cm4gZ2NjX2ppdF9sdmFsdWVfYWNjZXNzX2ZpZWxk IChvYmosICovCisvKiAJCQkJICAgICAgTlVMTCwgKi8KKy8qIAkJCQkgICAgICBjb21wLmxpc3Bf b2JqX2FzX3B0cik7ICovCisvKiB9ICovCiAKLSAgcmV0dXJuIGdjY19qaXRfbHZhbHVlX2FjY2Vz c19maWVsZCAob2JqLAotCQkJCSAgICAgIE5VTEwsCi0JCQkJICAgICAgY29tcC5saXNwX29ial9h c19wdHIpOwotfSAqLwogc3RhdGljIGdjY19qaXRfcnZhbHVlICoKLWVtaXRfWFVOVEFHIChnY2Nf aml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF90eXBlICp0eXBlLCBsb25nIGxvbmcgbGlzcF93b3JkX3Rh ZykKK2VtaXRfWFVOVEFHIChnY2Nfaml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF90eXBlICp0eXBlLCBM aXNwX1dvcmRfdGFnIGxpc3Bfd29yZF90YWcpCiB7CiAgIC8qICNkZWZpbmUgWFVOVEFHKGEsIHR5 cGUsIGN0eXBlKSAoKGN0eXBlICopCiAgICAgICgoY2hhciAqKSBYTFAgKGEpIC0gTElTUF9XT1JE X1RBRyAodHlwZSkpKSAqLwogICBlbWl0X2NvbW1lbnQgKCJYVU5UQUciKTsKIAotI2lmbmRlZiBX SURFX0VNQUNTX0lOVAogICByZXR1cm4gZW1pdF9jb2VyY2UgKAogCSAgIGdjY19qaXRfdHlwZV9n ZXRfcG9pbnRlciAodHlwZSksCiAJICAgZW1pdF9iaW5hcnlfb3AgKAogCSAgICAgR0NDX0pJVF9C SU5BUllfT1BfTUlOVVMsCi0JICAgICBjb21wLmVtYWNzX2ludF90eXBlLAotCSAgICAgZW1pdF9Y TEkgKGEpLAotCSAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKAotCSAg ICAgICBjb21wLmN0eHQsCi0JICAgICAgIGNvbXAuZW1hY3NfaW50X3R5cGUsCi0JICAgICAgIGxp c3Bfd29yZF90YWcpKSk7Ci0jZWxzZQotICByZXR1cm4gZW1pdF9jb2VyY2UgKAotCSAgIGdjY19q aXRfdHlwZV9nZXRfcG9pbnRlciAodHlwZSksCi0JICAgZW1pdF9iaW5hcnlfb3AgKAotCSAgICAg R0NDX0pJVF9CSU5BUllfT1BfTUlOVVMsCi0JICAgICBjb21wLnVuc2lnbmVkX2xvbmdfbG9uZ190 eXBlLAotCSAgICAgLyogRklYTUUgU2hvdWxkIGJlIFhMUC4gICovCi0JICAgICBlbWl0X1hMSSAo YSksCi0JICAgICBlbWl0X3J2YWx1ZV9mcm9tX2xvbmdfbG9uZyAobGlzcF93b3JkX3RhZykpKTsK LSNlbmRpZgorCSAgICAgY29tcC51aW50cHRyX3R5cGUsCisJICAgICBlbWl0X1hMUCAoYSksCisJ ICAgICBlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfd29yZF90YWcobGlzcF93b3JkX3RhZykpKTsKIH0K IAogc3RhdGljIGdjY19qaXRfcnZhbHVlICoKQEAgLTg1Myw3ICs5NzcsNyBAQCBlbWl0X0VRIChn Y2Nfaml0X3J2YWx1ZSAqeCwgZ2NjX2ppdF9ydmFsdWUgKnkpCiB9CiAKIHN0YXRpYyBnY2Nfaml0 X3J2YWx1ZSAqCi1lbWl0X1RBR0dFRFAgKGdjY19qaXRfcnZhbHVlICpvYmosIHB0cmRpZmZfdCB0 YWcpCitlbWl0X1RBR0dFRFAgKGdjY19qaXRfcnZhbHVlICpvYmosIExpc3BfV29yZF90YWcgdGFn KQogewogICAgLyogKCEgKCgodW5zaWduZWQpIChYTEkgKGEpID4+IChVU0VfTFNCX1RBRyA/IDAg OiBWQUxCSVRTKSkgXAogCS0gKHVuc2lnbmVkKSAodGFnKSkgXApAQCAtMTA1NCwxNyArMTE3OCw3 IEBAIGVtaXRfbWFrZV9maXhudW1fTFNCX1RBRyAoZ2NjX2ppdF9ydmFsdWUgKm4pCiAJCQljb21w LmVtYWNzX2ludF90eXBlLAogCQkJdG1wLCBjb21wLmxpc3BfaW50MCk7CiAKLSAgZ2NjX2ppdF9s dmFsdWUgKnJlcyA9IGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsIChjb21wLmZ1bmMsCi0JCQkJ CQkgICAgTlVMTCwKLQkJCQkJCSAgICBjb21wLmxpc3Bfb2JqX3R5cGUsCi0JCQkJCQkgICAgImxp c3Bfb2JqX2ZpeG51bSIpOwotCi0gIGdjY19qaXRfYmxvY2tfYWRkX2Fzc2lnbm1lbnQgKGNvbXAu YmxvY2ssCi0JCQkJTlVMTCwKLQkJCQllbWl0X2x2YWxfWExJIChyZXMpLAotCQkJCXRtcCk7Ci0K LSAgcmV0dXJuIGdjY19qaXRfbHZhbHVlX2FzX3J2YWx1ZSAocmVzKTsKKyAgcmV0dXJuIGVtaXRf Y29lcmNlIChjb21wLmxpc3Bfb2JqX3R5cGUsIHRtcCk7CiB9CiAKIHN0YXRpYyBnY2Nfaml0X3J2 YWx1ZSAqCkBAIC0xMDc2LDEwICsxMTkwLDggQEAgZW1pdF9tYWtlX2ZpeG51bV9NU0JfVEFHIChn Y2Nfaml0X3J2YWx1ZSAqbikKICAgICByZXR1cm4gWElMIChuKTsKICAgKi8KIAotICBnY2Nfaml0 X3J2YWx1ZSAqaW50bWFzayA9Ci0gICAgZW1pdF9jb2VyY2UgKGNvbXAuZW1hY3NfdWludF90eXBl LAotCQkgZW1pdF9ydmFsdWVfZnJvbV9sb25nX2xvbmcgKChFTUFDU19JTlRfTUFYCi0JCQkJCSAg ICAgID4+IChJTlRUWVBFQklUUyAtIDEpKSkpOworICBnY2Nfaml0X3J2YWx1ZSAqaW50bWFzayA9 IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfdWludCAoSU5UTUFTSyk7CisKICAgbiA9IGVtaXRfYmlu YXJ5X29wIChHQ0NfSklUX0JJTkFSWV9PUF9CSVRXSVNFX0FORCwKIAkJICAgICAgY29tcC5lbWFj c191aW50X3R5cGUsCiAJCSAgICAgIGludG1hc2ssIG4pOwpAQCAtMTA5MCwxMiArMTIwMiwxMCBA QCBlbWl0X21ha2VfZml4bnVtX01TQl9UQUcgKGdjY19qaXRfcnZhbHVlICpuKQogCQkgICAgZW1p dF9iaW5hcnlfb3AgKEdDQ19KSVRfQklOQVJZX09QX0xTSElGVCwKIAkJCQkgICAgY29tcC5lbWFj c191aW50X3R5cGUsCiAJCQkJICAgIGNvbXAubGlzcF9pbnQwLAotCQkJCSAgICBnY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCAoCi0JCQkJICAgICAgY29tcC5jdHh0LAotCQkJCSAg ICAgIGNvbXAuZW1hY3NfdWludF90eXBlLAotCQkJCSAgICAgIFZBTEJJVFMpKSwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfdWludChW QUxCSVRTKSksCiAJCSAgICBuKTsKLSAgcmV0dXJuIGVtaXRfWExJIChlbWl0X2NvZXJjZSAoY29t cC5lbWFjc19pbnRfdHlwZSwgbikpOworCisgIHJldHVybiBlbWl0X2NvZXJjZSAoY29tcC5saXNw X29ial90eXBlLCBuKTsKIH0KIAogCkBAIC0xMTE0LDE3ICsxMjI0LDEwIEBAIGVtaXRfY29uc3Rf bGlzcF9vYmogKExpc3BfT2JqZWN0IG9iaikKICAgZW1pdF9jb21tZW50IChmb3JtYXRfc3RyaW5n ICgiY29uc3QgbGlzcCBvYmo6ICVzIiwKIAkJCSAgICAgICBTU0RBVEEgKEZwcmluMV90b19zdHJp bmcgKG9iaiwgUW5pbCkpKSk7CiAKLSAgaWYgKE5JTF9JU19aRVJPICYmIEVRIChvYmosIFFuaWwp KQorICBpZiAoRVEgKG9iaiwgUW5pbCkpCiAgICAgewogICAgICAgZ2NjX2ppdF9ydmFsdWUgKm47 Ci0jaWZkZWYgV0lERV9FTUFDU19JTlQKLSAgICAgIGVhc3NlcnQgKE5JTF9JU19aRVJPKTsKLSAg ICAgIG4gPSBlbWl0X3J2YWx1ZV9mcm9tX2xvbmdfbG9uZyAoMCk7Ci0jZWxzZQotICAgICAgbiA9 IGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIChjb21wLmN0eHQsCi0JCQkJCSAg ICAgICBjb21wLnZvaWRfcHRyX3R5cGUsCi0JCQkJCSAgICAgICBOVUxMKTsKLSNlbmRpZgorICAg ICAgbiA9IGVtaXRfcnZhbHVlX2Zyb21fbGlzcF93b3JkICgoTGlzcF9Xb3JkKSBpUW5pbCk7CiAg ICAgICByZXR1cm4gZW1pdF9jb2VyY2UgKGNvbXAubGlzcF9vYmpfdHlwZSwgbik7CiAgICAgfQog CkBAIC0xMzQ1LDE2ICsxNDQ4LDcgQEAgZW1pdF9tdmFyX3ZhbCAoTGlzcF9PYmplY3QgbXZhcikK IAkgIC8qIFdlIGNhbiBzdGlsbCBlbWl0IGRpcmVjdGx5IG9iamVjdHMgdGhhdCBhcmUgc2VsZi1j b250YWluZWQgaW4gYQogCSAgICAgd29yZCAocmVhZCBmaXhudW1zKS4gICovCiAJICBlbWl0X2Nv bW1lbnQgKFNTREFUQSAoRnByaW4xX3RvX3N0cmluZyAoY29uc3RhbnQsIFFuaWwpKSk7Ci0JICBn Y2Nfaml0X3J2YWx1ZSAqd29yZDsKLSNpZmRlZiBXSURFX0VNQUNTX0lOVAotCSAgd29yZCA9IGVt aXRfcnZhbHVlX2Zyb21fbG9uZ19sb25nIChjb25zdGFudCk7Ci0jZWxzZQotCSAgd29yZCA9Ci0J ICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIChjb21wLmN0eHQsCi0JCQkJ CQkgY29tcC52b2lkX3B0cl90eXBlLAotCQkJCQkJIFhMUCAoY29uc3RhbnQpKTsKLSNlbmRpZgot CSAgcmV0dXJuIGVtaXRfY29lcmNlIChjb21wLmxpc3Bfb2JqX3R5cGUsIHdvcmQpOworICAgICAg ICAgIHJldHVybiBlbWl0X3J2YWx1ZV9mcm9tX2xpc3Bfb2JqKGNvbnN0YW50KTsKIAl9CiAgICAg ICAvKiBPdGhlciBjb25zdCBvYmplY3RzIGFyZSBmZXRjaGVkIGZyb20gdGhlIHJlbG9jIGFycmF5 LiAgKi8KICAgICAgIHJldHVybiBlbWl0X2NvbnN0X2xpc3Bfb2JqIChjb25zdGFudCk7CkBAIC0y NTE4LDExICsyNjEyLDE2IEBAIGRlZmluZV9jYXN0X3VuaW9uICh2b2lkKQogCQkJICAgICAgIE5V TEwsCiAJCQkgICAgICAgY29tcC5saXNwX2NvbnNfcHRyX3R5cGUsCiAJCQkgICAgICAgImNvbnNf cHRyIik7Ci0gIGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29iaiA9CisgIGNvbXAuY2FzdF91bmlv bl9hc19saXNwX3dvcmQgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4 dCwKIAkJCSAgICAgICBOVUxMLAotCQkJICAgICAgIGNvbXAubGlzcF9vYmpfdHlwZSwKLQkJCSAg ICAgICAibGlzcF9vYmoiKTsKKwkJCSAgICAgICBjb21wLmxpc3Bfd29yZF90eXBlLAorCQkJICAg ICAgICJsaXNwX3dvcmQiKTsKKyAgY29tcC5jYXN0X3VuaW9uX2FzX2xpc3Bfd29yZF90YWcgPQor ICAgIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bXAubGlzcF93b3JkX3RhZ190eXBlLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJs aXNwX3dvcmRfdGFnIik7CiAgIGNvbXAuY2FzdF91bmlvbl9hc19saXNwX29ial9wdHIgPQogICAg IGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKIAkJCSAgICAgICBOVUxMLApA QCAtMjU0Myw3ICsyNjQyLDggQEAgZGVmaW5lX2Nhc3RfdW5pb24gKHZvaWQpCiAgICAgICBjb21w LmNhc3RfdW5pb25fYXNfY19wLAogICAgICAgY29tcC5jYXN0X3VuaW9uX2FzX3ZfcCwKICAgICAg IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX2NvbnNfcHRyLAotICAgICAgY29tcC5jYXN0X3VuaW9u X2FzX2xpc3Bfb2JqLAorICAgICAgY29tcC5jYXN0X3VuaW9uX2FzX2xpc3Bfd29yZCwKKyAgICAg IGNvbXAuY2FzdF91bmlvbl9hc19saXNwX3dvcmRfdGFnLAogICAgICAgY29tcC5jYXN0X3VuaW9u X2FzX2xpc3Bfb2JqX3B0ciB9OwogICBjb21wLmNhc3RfdW5pb25fdHlwZSA9CiAgICAgZ2NjX2pp dF9jb250ZXh0X25ld191bmlvbl90eXBlIChjb21wLmN0eHQsCkBAIC0yODEwLDggKzI5MTAsOCBA QCBkZWZpbmVfYWRkMV9zdWIxICh2b2lkKQogCQkJCQkgIEdDQ19KSVRfQ09NUEFSSVNPTl9ORSwK IAkJCQkJICBuX2ZpeG51bSwKIAkJCQkJICBpID09IDAKLQkJCQkJICA/IGVtaXRfbW9zdF9wb3Np dGl2ZV9maXhudW0gKCkKLQkJCQkJICA6IGVtaXRfbW9zdF9uZWdhdGl2ZV9maXhudW0gKCkpKSwK KwkJCQkJICA/IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX1BPU0lUSVZFX0ZJWE5V TSkKKwkJCQkJICA6IGVtaXRfcnZhbHVlX2Zyb21fZW1hY3NfaW50IChNT1NUX05FR0FUSVZFX0ZJ WE5VTSkpKSwKIAlpbmxpbmVfYmxvY2ssCiAJZmNhbGxfYmxvY2spOwogCkBAIC0zMzA3LDkgKzM0 MDcsMzEgQEAgREVGVU4gKCJjb21wLS1pbml0LWN0eHQiLCBGY29tcF9faW5pdF9jdHh0LCBTY29t cF9faW5pdF9jdHh0LAogICBjb21wLmVtYWNzX3VpbnRfdHlwZSA9IGdjY19qaXRfY29udGV4dF9n ZXRfaW50X3R5cGUgKGNvbXAuY3R4dCwKIAkJCQkJCSAgICAgICBzaXplb2YgKEVNQUNTX1VJTlQp LAogCQkJCQkJICAgICAgIGZhbHNlKTsKLSAgLyogTm8gWExQIGlzIGVtaXR0ZWQgZm9yIG5vdyBz byBsZXRzIGRlZmluZSB0aGlzIGFsd2F5cyBhcyBpbnRlZ2VyCi0gICAgIGRpc3JlZ2FyZGluZyBM SVNQX1dPUkRTX0FSRV9QT0lOVEVSUyB2YWx1ZS4gICovCi0gIGNvbXAubGlzcF9vYmpfdHlwZSA9 IGNvbXAuZW1hY3NfaW50X3R5cGU7CisjaWYgTElTUF9XT1JEU19BUkVfUE9JTlRFUlMKKyAgY29t cC5saXNwX1hfcyA9IGdjY19qaXRfY29udGV4dF9uZXdfb3BhcXVlX3N0cnVjdCAoY29tcC5jdHh0 LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBO VUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAiTGlzcF9YIik7CisgIGNvbXAubGlzcF9YID0gZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZShjb21w Lmxpc3BfWF9zKTsKKyAgY29tcC5saXNwX3dvcmRfdHlwZSA9IGdjY19qaXRfdHlwZV9nZXRfcG9p bnRlcihjb21wLmxpc3BfWCk7CisjZWxzZQorICBjb21wLmxpc3Bfd29yZF90eXBlID0gY29tcC5l bWFjc19pbnRfdHlwZTsKKyNlbmRpZgorICBjb21wLmxpc3Bfd29yZF90YWdfdHlwZQorICAgID0g Z2NjX2ppdF9jb250ZXh0X2dldF9pbnRfdHlwZSAoY29tcC5jdHh0LCBzaXplb2YgKExpc3BfV29y ZF90YWcpLCBmYWxzZSk7CisjaWZkZWYgTElTUF9PQkpFQ1RfSVNfU1RSVUNUCisgIGNvbXAubGlz cF9vYmpfaSA9IGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQgKGNvbXAuY3R4dCwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcC5saXNwX3dvcmRfdHlwZSwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImkiKTsKKyAg Y29tcC5saXNwX29ial9zID0gZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfdHlwZSAoY29tcC5j dHh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBOVUxMLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiTGlzcF9PYmplY3QiLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAxLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmY29tcC5saXNwX29ial9pKTsKKyAgY29tcC5saXNwX29ial90eXBl ID0gZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZSAoY29tcC5saXNwX29ial9zKTsKKyNlbHNlCisgIGNv bXAubGlzcF9vYmpfdHlwZSA9IGNvbXAubGlzcF93b3JkX3R5cGU7CisjZW5kaWYKICAgY29tcC5s aXNwX29ial9wdHJfdHlwZSA9IGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciAoY29tcC5saXNwX29i al90eXBlKTsKICAgY29tcC5vbmUgPQogICAgIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zy b21faW50IChjb21wLmN0eHQsCmRpZmYgLS1naXQgYS9zcmMvbGlzcC5oIGIvc3JjL2xpc3AuaApp bmRleCA4MzRiM2U1ODZjLi5lMjQyNTQ2ZDEwIDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBi L3NyYy9saXNwLmgKQEAgLTI5OSwxMiArMjk5LDEyIEBAICNkZWZpbmUgR0NBTElHTkVEKHR5cGUp IChhbGlnbm9mICh0eXBlKSAlIEdDQUxJR05NRU5UID09IDApCiAKIC8qIExpc3BfV29yZCBpcyBh IHNjYWxhciB3b3JkIHN1aXRhYmxlIGZvciBob2xkaW5nIGEgdGFnZ2VkIHBvaW50ZXIgb3IKICAg IGludGVnZXIuICBVc3VhbGx5IGl0IGlzIGEgcG9pbnRlciB0byBhIGRlbGliZXJhdGVseS1pbmNv bXBsZXRlIHR5cGUKLSAgICd1bmlvbiBMaXNwX1gnLiAgSG93ZXZlciwgaXQgaXMgRU1BQ1NfSU5U IHdoZW4gTGlzcF9PYmplY3RzIGFuZAorICAgJ3N0cnVjdCBMaXNwX1gnLiAgSG93ZXZlciwgaXQg aXMgRU1BQ1NfSU5UIHdoZW4gTGlzcF9PYmplY3RzIGFuZAogICAgcG9pbnRlcnMgZGlmZmVyIGlu IHdpZHRoLiAgKi8KIAogI2RlZmluZSBMSVNQX1dPUkRTX0FSRV9QT0lOVEVSUyAoRU1BQ1NfSU5U X01BWCA9PSBJTlRQVFJfTUFYKQogI2lmIExJU1BfV09SRFNfQVJFX1BPSU5URVJTCi10eXBlZGVm IHVuaW9uIExpc3BfWCAqTGlzcF9Xb3JkOwordHlwZWRlZiBzdHJ1Y3QgTGlzcF9YICpMaXNwX1dv cmQ7CiAjZWxzZQogdHlwZWRlZiBFTUFDU19JTlQgTGlzcF9Xb3JkOwogI2VuZGlmCkBAIC01NzMs NiArNTczLDcgQEAgI2RlZmluZSBFTlVNX0JGKFRZUEUpIGVudW0gVFlQRQogCiAjaWZkZWYgQ0hF Q0tfTElTUF9PQkpFQ1RfVFlQRQogdHlwZWRlZiBzdHJ1Y3QgTGlzcF9PYmplY3QgeyBMaXNwX1dv cmQgaTsgfSBMaXNwX09iamVjdDsKKyMgZGVmaW5lIExJU1BfT0JKRUNUX0lTX1NUUlVDVAogIyBk ZWZpbmUgTElTUF9JTklUSUFMTFkodykge3d9CiAjIHVuZGVmIENIRUNLX0xJU1BfT0JKRUNUX1RZ UEUKIGVudW0gQ0hFQ0tfTElTUF9PQkpFQ1RfVFlQRSB7IENIRUNLX0xJU1BfT0JKRUNUX1RZUEUg PSB0cnVlIH07Ci0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Disposition: attachment; filename="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5se0 RnJvbSBhNzE3NmE2NGQ0ZDg4Mjg3NGQ0YTgxY2MzOTI0ZTAzZmEyYTA5Y2U4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAxMyBNYXkgMjAyMCAxODoz MTo0MiAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMS85XSBEZXRlcm1pbmUgdGhlIGVtYWNzIHJvb3Qg ZGlyIG9ubHkgd2hlbiBuZWNlc3NhcnkuCgoqIHNyYy9maWxlaW8uYzogSW50cm9kdWNlIGZ1bmN0 aW9uIGVtYWNzX3Jvb3RfZGlyKCkuIFJlZmFjdG9yCmBleHBhbmQtZmlsZS1uYW1lYCB0byB1c2Ug aXQuCiogc3JjL2xpc3AuaDogU2VwYXJhdGUgZW1hY3Nfcm9vdF9kaXIoKSBpbnRvIGRvc19lbWFj c19yb290X2RpcigpIGFuZAp3MzJfZW1hY3Nfcm9vdF9kaXIoKS4KKiBzcmMvbXNkb3MuYzogUmVu YW1lIGVtYWNzX3Jvb3RfZGlyKCkgdG8gZG9zX2VtYWNzX3Jvb3RfZGlyKCkuCiogc3JjL3czMi5j OiBSZW5hbWUgZW1hY3Nfcm9vdF9kaXIoKSB0byB3MzJfZW1hY3Nfcm9vdF9kaXIoKS4KLS0tCiBz cmMvZmlsZWlvLmMgfCAzNyArKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tCiBz cmMvbGlzcC5oICAgfCAxMSArKysrKysrLS0tLQogc3JjL21zZG9zLmMgIHwgIDIgKy0KIHNyYy93 MzIuYyAgICB8ICAyICstCiA0IGZpbGVzIGNoYW5nZWQsIDMxIGluc2VydGlvbnMoKyksIDIxIGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9maWxlaW8uYyBiL3NyYy9maWxlaW8uYwppbmRl eCAyZjFkMmY4MjQzLi5lMjBmYTkzYzY1IDEwMDY0NAotLS0gYS9zcmMvZmlsZWlvLmMKKysrIGIv c3JjL2ZpbGVpby5jCkBAIC03ODEsNiArNzgxLDE4IEBAIHVzZXJfaG9tZWRpciAoY2hhciBjb25z dCAqbmFtZSkKICAgcmV0dXJuIHB3LT5wd19kaXI7CiB9CiAKK3N0YXRpYyBMaXNwX09iamVjdAor ZW1hY3Nfcm9vdF9kaXIoKQoreworI2lmZGVmIERPUworICAgICAgcmV0dXJuIGJ1aWxkX3N0cmlu ZyAoZG9zX2VtYWNzX3Jvb3RfZGlyICgpKTsKKyNlbGlmIGRlZmluZWQoV0lORE9XU05UKQorICAg ICAgcmV0dXJuIGJ1aWxkX3N0cmluZyAodzMyX2VtYWNzX3Jvb3RfZGlyICgpKTsKKyNlbHNlCisg ICAgICByZXR1cm4gYnVpbGRfc3RyaW5nICgiLyIpOworI2VuZGlmCit9CisKIERFRlVOICgiZXhw YW5kLWZpbGUtbmFtZSIsIEZleHBhbmRfZmlsZV9uYW1lLCBTZXhwYW5kX2ZpbGVfbmFtZSwgMSwg MiwgMCwKICAgICAgICBkb2M6IC8qIENvbnZlcnQgZmlsZW5hbWUgTkFNRSB0byBhYnNvbHV0ZSwg YW5kIGNhbm9uaWNhbGl6ZSBpdC4KIFNlY29uZCBhcmcgREVGQVVMVC1ESVJFQ1RPUlkgaXMgZGly ZWN0b3J5IHRvIHN0YXJ0IHdpdGggaWYgTkFNRSBpcyByZWxhdGl2ZQpAQCAtODUxLDIxICs4NjMs MTYgQEAgREVGVU4gKCJleHBhbmQtZmlsZS1uYW1lIiwgRmV4cGFuZF9maWxlX25hbWUsIFNleHBh bmRfZmlsZV9uYW1lLCAxLCAyLCAwLAogICAgIH0KIAogICAvKiBBcyBhIGxhc3QgcmVzb3J0LCB3 ZSBtYXkgaGF2ZSB0byB1c2UgdGhlIHJvb3QgYXMKLSAgICAgZGVmYXVsdF9kaXJlY3RvcnkgYmVs b3cuICAqLwotICBMaXNwX09iamVjdCByb290OwotI2lmZGVmIERPU19OVAotICAgICAgLyogIi8i IGlzIG5vdCBjb25zaWRlcmVkIGEgcm9vdCBkaXJlY3Rvcnkgb24gRE9TX05ULCBzbyB1c2luZyBp dAotCSBhcyBkZWZhdWx0X2RpcmVjdG9yeSBjYXVzZXMgYW4gaW5maW5pdGUgcmVjdXJzaW9uIGlu LCBlLmcuLAotCSB0aGUgZm9sbG93aW5nOgorICAgICBkZWZhdWx0X2RpcmVjdG9yeSBiZWxvdy4K IAotICAgICAgICAgICAgKGxldCAoZGVmYXVsdC1kaXJlY3RvcnkpCi0JICAgICAgKGV4cGFuZC1m aWxlLW5hbWUgImEiKSkKKyAgICAgIi8iIGlzIG5vdCBjb25zaWRlcmVkIGEgcm9vdCBkaXJlY3Rv cnkgb24gRE9TX05ULCBzbyB1c2luZyBpdAorICAgICBhcyBkZWZhdWx0X2RpcmVjdG9yeSBjYXVz ZXMgYW4gaW5maW5pdGUgcmVjdXJzaW9uIGluLCBlLmcuLAorICAgICB0aGUgZm9sbG93aW5nOgog Ci0JIFRvIGF2b2lkIHRoaXMsIHdlIHVzZSB0aGUgcm9vdCBvZiB0aGUgY3VycmVudCBkcml2ZS4g ICovCi0gICAgICByb290ID0gYnVpbGRfc3RyaW5nIChlbWFjc19yb290X2RpciAoKSk7Ci0jZWxz ZQotICAgICAgcm9vdCA9IGJ1aWxkX3N0cmluZyAoIi8iKTsKLSNlbmRpZgorICAgICAgICAobGV0 IChkZWZhdWx0LWRpcmVjdG9yeSkKKyAgICAgICAgICAoZXhwYW5kLWZpbGUtbmFtZSAiYSIpKQor CisgICAgIFRvIGF2b2lkIHRoaXMsIHdlIHVzZSB0aGUgcm9vdCBvZiB0aGUgY3VycmVudCBkcml2 ZS4gICovCiAKICAgLyogVXNlIHRoZSBidWZmZXIncyBkZWZhdWx0LWRpcmVjdG9yeSBpZiBERUZB VUxUX0RJUkVDVE9SWSBpcyBvbWl0dGVkLiAgKi8KICAgaWYgKE5JTFAgKGRlZmF1bHRfZGlyZWN0 b3J5KSkKQEAgLTg5MSwxMyArODk4LDEzIEBAIERFRlVOICgiZXhwYW5kLWZpbGUtbmFtZSIsIEZl eHBhbmRfZmlsZV9uYW1lLCBTZXhwYW5kX2ZpbGVfbmFtZSwgMSwgMiwgMCwKIAkgICAgICBMaXNw X09iamVjdCBhYnNkaXIKIAkJPSBTVFJJTkdQIChWaW52b2NhdGlvbl9kaXJlY3RvcnkpCiAJCSYm IGZpbGVfbmFtZV9hYnNvbHV0ZV9ub190aWxkZV9wIChWaW52b2NhdGlvbl9kaXJlY3RvcnkpCi0J CT8gVmludm9jYXRpb25fZGlyZWN0b3J5IDogcm9vdDsKKwkJPyBWaW52b2NhdGlvbl9kaXJlY3Rv cnkgOiBlbWFjc19yb290X2RpcigpOwogCSAgICAgIGRlZmF1bHRfZGlyZWN0b3J5ID0gRmV4cGFu ZF9maWxlX25hbWUgKGRpciwgYWJzZGlyKTsKIAkgICAgfQogCX0KICAgICB9CiAgIGlmICghIFNU UklOR1AgKGRlZmF1bHRfZGlyZWN0b3J5KSkKLSAgICBkZWZhdWx0X2RpcmVjdG9yeSA9IHJvb3Q7 CisgICAgZGVmYXVsdF9kaXJlY3RvcnkgPSBlbWFjc19yb290X2RpcigpOwogCiAgIGhhbmRsZXIg PSBGZmluZF9maWxlX25hbWVfaGFuZGxlciAoZGVmYXVsdF9kaXJlY3RvcnksIFFleHBhbmRfZmls ZV9uYW1lKTsKICAgaWYgKCFOSUxQIChoYW5kbGVyKSkKZGlmZiAtLWdpdCBhL3NyYy9saXNwLmgg Yi9zcmMvbGlzcC5oCmluZGV4IDNkMDgyOTExZjUuLjgzNGIzZTU4NmMgMTAwNjQ0Ci0tLSBhL3Ny Yy9saXNwLmgKKysrIGIvc3JjL2xpc3AuaApAQCAtNDcxOSwxMCArNDcxOSwxMyBAQCBtYXliZV9k aXNhYmxlX2FkZHJlc3NfcmFuZG9taXphdGlvbiAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogZXh0 ZXJuIHZvaWQgbWFsbG9jX3Byb2JlIChzaXplX3QpOwogZXh0ZXJuIHZvaWQgc3ltc19vZl9wcm9m aWxlciAodm9pZCk7CiAKLSNpZmRlZiBET1NfTlQKLS8qIERlZmluZWQgaW4gbXNkb3MuYywgdzMy LmMuICAqLwotZXh0ZXJuIGNoYXIgKmVtYWNzX3Jvb3RfZGlyICh2b2lkKTsKLSNlbmRpZiAvKiBE T1NfTlQgKi8KKyNpZmRlZiBNU0RPUworLyogRGVmaW5lZCBpbiBtc2Rvcy5jLiAgKi8KK2V4dGVy biBjaGFyICpkb3NfZW1hY3Nfcm9vdF9kaXIgKHZvaWQpOworI2VsaWYgZGVmaW5lZChXSU5ET1dT TlQpCisvKiBEZWZpbmVkIGluIHczMi5jLiAgKi8KK2V4dGVybiBjaGFyICp3MzJfZW1hY3Nfcm9v dF9kaXIgKHZvaWQpOworI2VuZGlmIC8qIE1TRE9TICovCiAKICNpZmRlZiBIQVZFX05BVElWRV9D T01QCiBJTkxJTkUgYm9vbApkaWZmIC0tZ2l0IGEvc3JjL21zZG9zLmMgYi9zcmMvbXNkb3MuYwpp bmRleCBiNWYwNmM5OWMzLi4wODI3Y2M5NmNkIDEwMDY0NAotLS0gYS9zcmMvbXNkb3MuYworKysg Yi9zcmMvbXNkb3MuYwpAQCAtMzM1MCw3ICszMzUwLDcgQEAgZ2V0ZGVmZGlyIChpbnQgZHJpdmUs IGNoYXIgKmRzdCkKIH0KIAogY2hhciAqCi1lbWFjc19yb290X2RpciAodm9pZCkKK2Rvc19lbWFj c19yb290X2RpciAodm9pZCkKIHsKICAgc3RhdGljIGNoYXIgcm9vdF9kaXJbNF07CiAKZGlmZiAt LWdpdCBhL3NyYy93MzIuYyBiL3NyYy93MzIuYwppbmRleCAwZjY5ZTY1MmE1Li4xZWMwMDk0Yzhl IDEwMDY0NAotLS0gYS9zcmMvdzMyLmMKKysrIGIvc3JjL3czMi5jCkBAIC0zMTQ3LDcgKzMxNDcs NyBAQCAjZGVmaW5lIFNFVF9FTlZfQlVGX1NJWkUgKDQgKiBNQVhfUEFUSCkJLyogdG8gY292ZXIg RU1BQ1NMT0FEUEFUSCAqLwogLyogQ2FsbGVkIGZyb20gZXhwYW5kLWZpbGUtbmFtZSB3aGVuIGRl ZmF1bHQtZGlyZWN0b3J5IGlzIG5vdCBhIHN0cmluZy4gICovCiAKIGNoYXIgKgotZW1hY3Nfcm9v dF9kaXIgKHZvaWQpCit3MzJfZW1hY3Nfcm9vdF9kaXIgKHZvaWQpCiB7CiAgIHN0YXRpYyBjaGFy IHJvb3RfZGlyW01BWF9VVEY4X1BBVEhdOwogICBjb25zdCBjaGFyICpwOwotLSAKMi4yNS4xLndp bmRvd3MuMQoK --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0002-Do-not-block-SIGIO-in-platforms-that-don-t-have-it.patch" Content-Disposition: attachment; filename="0002-Do-not-block-SIGIO-in-platforms-that-don-t-have-it.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5ts1 RnJvbSBlOGUyMjRmYmY5N2M2MzQ2YTM1NTgyMGU2MmFhNDIzOWE5YzYzYTg2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE2OjAy OjU4IC0wMzAwClN1YmplY3Q6IFtQQVRDSCAyLzldIERvIG5vdCBibG9jayBTSUdJTyBpbiBwbGF0 Zm9ybXMgdGhhdCBkb24ndCBoYXZlIGl0LgoKKiBzcmMvY29tcC5jIChjb21wLS1jb21waWxlLWN0 eHQtdG8tZmlsZSk6IEFkZCBhIHByZXByb2Nlc3NvciBjaGVjayB0bwphdm9pZCBibG9ja2luZyBT SUdJTyBpbiBwbGF0Zm9ybXMgdGhhdCBkb24ndCBoYXZlIGl0LgotLS0KIHNyYy9jb21wLmMgfCAy ICsrCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2Nv bXAuYyBiL3NyYy9jb21wLmMKaW5kZXggZTNhODBhZGZhOS4uMDBmOWQ0Yjc0YSAxMDA2NDQKLS0t IGEvc3JjL2NvbXAuYworKysgYi9zcmMvY29tcC5jCkBAIC0zMzQ1LDcgKzMzNDUsOSBAQCBERUZV TiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBfX2NvbXBpbGVfY3R4dF90b19m aWxlLAogICAgICAgc2lnZW1wdHlzZXQgKCZibG9ja2VkKTsKICAgICAgIHNpZ2FkZHNldCAoJmJs b2NrZWQsIFNJR0FMUk0pOwogICAgICAgc2lnYWRkc2V0ICgmYmxvY2tlZCwgU0lHSU5UKTsKKyNp ZmRlZiBVU0FCTEVfU0lHSU8KICAgICAgIHNpZ2FkZHNldCAoJmJsb2NrZWQsIFNJR0lPKTsKKyNl bmRpZgogICAgICAgcHRocmVhZF9zaWdtYXNrIChTSUdfQkxPQ0ssICZibG9ja2VkLCAmb2xkc2V0 KTsKICAgICB9CiAgIGVtaXRfY3R4dF9jb2RlICgpOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch" Content-Disposition: attachment; filename="0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5uz4 RnJvbSA4ZGJlMGM5OWVjYmFhMWIxNTNjYTZiM2FmMDJmOWI1ZTk2ZDYzZDBiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE2OjIz OjEwIC0wMzAwClN1YmplY3Q6IFtQQVRDSCA1LzldIFJlbW92ZSBhIGxheWVyIG9mIGluZGlyZWN0 aW9uIGZvciBhY2Nlc3MgdG8gcHVyZSBzdG9yYWdlLgoKKiBzcmMvY29tcC5jOiBUYWtpbmcgdGhl IGFkZHJlc3Mgb2YgYW4gYXJyYXkgaXMgdGhlIHNhbWUgYXMgY2FzdGluZyBpdAp0byBhIHBvaW50 ZXIuIFRoZXJlZm9yZSwgdGhlIEMgZXhwcmVzc2lvbiBgKEVNQUNTX0lOVCAqKikgJnB1cmVgIGlz IGluCmZhY3QgYWRkaW5nIGEgbGF5ZXIgb2YgaW5kaXJlY3Rpb24gdGhhdCBpcyBub3QgbmVjZXNz YXJ5LiBUaGUgZml4IGlzCnRvIGNhc3QgdGhlIGBwdXJlYCBhcnJheSB0byBhIHBvaW50ZXIgYW5k IHN0b3JlIHRoYXQgaW4gYSB2b2lkIHBvaW50ZXIKdGhhdCBpcyBwYXJ0IG9mIHRoZSBjb21waWxl ZCBzaGFyZWQgbGlicmFyeS4KLS0tCiBzcmMvY29tcC5jIHwgMTkgKysrKysrKysrLS0tLS0tLS0t LQogMSBmaWxlIGNoYW5nZWQsIDkgaW5zZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pCgpkaWZm IC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9jb21wLmMKaW5kZXggMGQ1ODgwYWQzYy4uNjk1MjVh Y2ZjMCAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9zcmMvY29tcC5jCkBAIC0zOCw3ICsz OCw3IEBACiAKIC8qIEMgc3ltYm9scyBlbWl0dGVkIGZvciB0aGUgbG9hZCByZWxvY2F0aW9uIG1l Y2hhbmlzbS4gICovCiAjZGVmaW5lIENVUlJFTlRfVEhSRUFEX1JFTE9DX1NZTSAiY3VycmVudF90 aHJlYWRfcmVsb2MiCi0jZGVmaW5lIFBVUkVfUkVMT0NfU1lNICJwdXJlX3JlbG9jIgorI2RlZmlu ZSBQVVJFX1BUUl9TWU0gInB1cmVfcHRyIgogI2RlZmluZSBEQVRBX1JFTE9DX1NZTSAiZF9yZWxv YyIKICNkZWZpbmUgREFUQV9SRUxPQ19JTVBVUkVfU1lNICJkX3JlbG9jX2ltcCIKICNkZWZpbmUg REFUQV9SRUxPQ19FUEhFTUVSQUxfU1lNICJkX3JlbG9jX2VwaCIKQEAgLTE1Miw3ICsxNTIsNyBA QCAjZGVmaW5lIEZfUkVMT0NfTUFYX1NJWkUgMTUwMAogICBnY2Nfaml0X3R5cGUgKnRocmVhZF9z dGF0ZV9wdHJfdHlwZTsKICAgZ2NjX2ppdF9ydmFsdWUgKmN1cnJlbnRfdGhyZWFkX3JlZjsKICAg LyogT3RoZXIgZ2xvYmFscy4gICovCi0gIGdjY19qaXRfcnZhbHVlICpwdXJlX3JlZjsKKyAgZ2Nj X2ppdF9ydmFsdWUgKnB1cmVfcHRyOwogICAvKiBsaWJnY2NqaXQgaGFzIHJlYWxseSBsaW1pdGVk IHN1cHBvcnQgZm9yIGNhc3RpbmcgdGhlcmVmb3JlIHRoaXMgdW5pb24gd2lsbAogICAgICBiZSB1 c2VkIGZvciB0aGUgc2NvcGUuICAqLwogICBnY2Nfaml0X3R5cGUgKmNhc3RfdW5pb25fdHlwZTsK QEAgLTE0MTksOCArMTQxOSw3IEBAIGVtaXRfUFVSRV9QIChnY2Nfaml0X3J2YWx1ZSAqcHRyKQog CUdDQ19KSVRfQklOQVJZX09QX01JTlVTLAogCWNvbXAudWludHB0cl90eXBlLAogCXB0ciwKLQln Y2Nfaml0X2x2YWx1ZV9hc19ydmFsdWUgKAotCSAgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2Ug KGNvbXAucHVyZV9yZWYsIE5VTEwpKSksCisgICAgICAgIGNvbXAucHVyZV9wdHIpLAogICAgICAg Z2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQgKGNvbXAuY3R4dCwKIAkJCQkJICAg Y29tcC51aW50cHRyX3R5cGUsCiAJCQkJCSAgIFBVUkVTSVpFKSk7CkBAIC0yMjQ0LDE0ICsyMjQz LDE0IEBAIGVtaXRfY3R4dF9jb2RlICh2b2lkKQogCWdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciAo Y29tcC50aHJlYWRfc3RhdGVfcHRyX3R5cGUpLAogCUNVUlJFTlRfVEhSRUFEX1JFTE9DX1NZTSkp OwogCi0gIGNvbXAucHVyZV9yZWYgPQorICBjb21wLnB1cmVfcHRyID0KICAgICBnY2Nfaml0X2x2 YWx1ZV9hc19ydmFsdWUgKAogICAgICAgZ2NjX2ppdF9jb250ZXh0X25ld19nbG9iYWwgKAogCWNv bXAuY3R4dCwKIAlOVUxMLAogCUdDQ19KSVRfR0xPQkFMX0VYUE9SVEVELAotCWdjY19qaXRfdHlw ZV9nZXRfcG9pbnRlciAoY29tcC52b2lkX3B0cl90eXBlKSwKLQlQVVJFX1JFTE9DX1NZTSkpOwor ICAgICAgICBjb21wLnZvaWRfcHRyX3R5cGUsCisJUFVSRV9QVFJfU1lNKSk7CiAKICAgZ2NjX2pp dF9jb250ZXh0X25ld19nbG9iYWwgKAogCWNvbXAuY3R4dCwKQEAgLTM3NjcsMTMgKzM3NjYsMTMg QEAgbG9hZF9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKmNvbXBfdSwg Ym9vbCBsb2FkaW5nX2R1bXAsCiAgICAgewogICAgICAgc3RydWN0IHRocmVhZF9zdGF0ZSAqKipj dXJyZW50X3RocmVhZF9yZWxvYyA9CiAJZHlubGliX3N5bSAoaGFuZGxlLCBDVVJSRU5UX1RIUkVB RF9SRUxPQ19TWU0pOwotICAgICAgRU1BQ1NfSU5UICoqKnB1cmVfcmVsb2MgPSBkeW5saWJfc3lt IChoYW5kbGUsIFBVUkVfUkVMT0NfU1lNKTsKKyAgICAgIHZvaWQgKipwdXJlX3B0ciA9IGR5bmxp Yl9zeW0gKGhhbmRsZSwgUFVSRV9QVFJfU1lNKTsKICAgICAgIExpc3BfT2JqZWN0ICpkYXRhX3Jl bG9jcyA9IGR5bmxpYl9zeW0gKGhhbmRsZSwgREFUQV9SRUxPQ19TWU0pOwogICAgICAgTGlzcF9P YmplY3QgKmRhdGFfaW1wX3JlbG9jcyA9IGR5bmxpYl9zeW0gKGhhbmRsZSwgREFUQV9SRUxPQ19J TVBVUkVfU1lNKTsKICAgICAgIHZvaWQgKipmcmVsb2NfbGlua190YWJsZSA9IGR5bmxpYl9zeW0g KGhhbmRsZSwgRlVOQ19MSU5LX1RBQkxFX1NZTSk7CiAKICAgICAgIGlmICghKGN1cnJlbnRfdGhy ZWFkX3JlbG9jCi0JICAgICYmIHB1cmVfcmVsb2MKKwkgICAgJiYgcHVyZV9wdHIKIAkgICAgJiYg ZGF0YV9yZWxvY3MKIAkgICAgJiYgZGF0YV9pbXBfcmVsb2NzCiAJICAgICYmIGRhdGFfZXBoX3Jl bG9jcwpAQCAtMzc4NCw3ICszNzgzLDcgQEAgbG9hZF9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05h dGl2ZV9Db21wX1VuaXQgKmNvbXBfdSwgYm9vbCBsb2FkaW5nX2R1bXAsCiAJeHNpZ25hbDEgKFFu YXRpdmVfbGlzcF9maWxlX2luY29uc2lzdGVudCwgY29tcF91LT5maWxlKTsKIAogICAgICAgKmN1 cnJlbnRfdGhyZWFkX3JlbG9jID0gJmN1cnJlbnRfdGhyZWFkOwotICAgICAgKnB1cmVfcmVsb2Mg PSAoRU1BQ1NfSU5UICoqKSZwdXJlOworICAgICAgKnB1cmVfcHRyID0gcHVyZTsKIAogICAgICAg LyogSW1wb3J0ZWQgZnVuY3Rpb25zLiAgKi8KICAgICAgICpmcmVsb2NfbGlua190YWJsZSA9IGZy ZWxvYy5saW5rX3RhYmxlOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0008-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Disposition: attachment; filename="0008-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5vf7 RnJvbSAxZmI1YzM4NzQ4YzEyNzM1ZWUxZDZlYjZlNzk0ZDYxNzIwZTRmYzExIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogV2VkLCAxMyBNYXkgMjAyMCAxNjoy MjoxNyAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggOC85XSBXaW5kb3dzOiBVc2UgTlVNQkVSX09GX1BS T0NFU1NPUlMgZW52aXJvbm1lbnQgdmFyaWFibGUuCgoqIGxpc3AvZW1hY3MtbGlzcC9jb21wLmVs IChjb21wLWVmZmVjdGl2ZS1hc3luYy1tYXgtam9icyk6IFVzZQpOVU1CRVJfT0ZfUFJPQ0VTU09S UyBlbnZpcm9ubWVudCB2YXJpYWJsZSBpZiBzeXN0ZW0gaXMgV2luZG93cyBOVCwKIm5wcm9jIiBp ZiBpdCBpcyBpbiBQQVRIIG9yIGEgZGVmYXVsdCBvZiAxLgotLS0KIGxpc3AvZW1hY3MtbGlzcC9j b21wLmVsIHwgOCArKysrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgMyBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCBiL2xpc3Av ZW1hY3MtbGlzcC9jb21wLmVsCmluZGV4IGQzMmY5M2ExZTEuLjI2YmI3OWZjZDEgMTAwNjQ0Ci0t LSBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCisrKyBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVs CkBAIC0yMjA4LDkgKzIyMDgsMTEgQEAgY29tcC1hc3luYy1ydW5uaW5ncwogICAgIChpZiAoemVy b3AgY29tcC1hc3luYy1qb2JzLW51bWJlcikKICAgICAgICAgKG9yIG51bS1jcHVzCiAgICAgICAg ICAgICAoc2V0ZiBudW0tY3B1cwotICAgICAgICAgICAgICAgICAgOzsgSGFsZiBvZiB0aGUgQ1BV cyBvciBhdCBsZWFzdCBvbmUuCi0gICAgICAgICAgICAgICAgICA7OyBGSVhNRSBwb3J0YWJsZT8K LSAgICAgICAgICAgICAgICAgIChtYXggMSAoLyAoc3RyaW5nLXRvLW51bWJlciAoc2hlbGwtY29t bWFuZC10by1zdHJpbmcgIm5wcm9jIikpCisgICAgICAgICAgICAgICAgICAobWF4IDEgKC8gKGNv bmQgKChlcSAnd2luZG93cy1udCBzeXN0ZW0tdHlwZSkKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKHN0cmluZy10by1udW1iZXIgKGdldGVudiAiTlVNQkVSX09GX1BST0NFU1NP UlMiKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKChleGVjdXRhYmxlLWZp bmQgIm5wcm9jIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmluZy10 by1udW1iZXIgKHNoZWxsLWNvbW1hbmQtdG8tc3RyaW5nICJucHJvYyIpKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAodCAxKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAyKSkpKQogICAgICAgY29tcC1hc3luYy1qb2JzLW51bWJlcikpKQogCi0tIAoyLjI1LjEud2lu ZG93cy4xCgo= --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0009-Improve-handling-of-native-compilation-units-still-i.patch" Content-Disposition: attachment; filename="0009-Improve-handling-of-native-compilation-units-still-i.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5vi8 RnJvbSBkNWVlNDE4NWE5ZjIzNDYyY2RiM2ZhMzRjYWZlZjUwOGRkYjliODFiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogVHVlLCAxOSBNYXkgMjAyMCAxNTo1 NzozMSAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggOS85XSBJbXByb3ZlIGhhbmRsaW5nIG9mIG5hdGl2 ZSBjb21waWxhdGlvbiB1bml0cyBzdGlsbCBpbiB1c2UKIGluIFdpbmRvd3MKCldoZW4gY2xvc2lu ZyBlbWFjcyB3aWxsIGluc3BlY3QgYWxsIGRpcmVjdG9yaWVzIGZyb20gd2hpY2ggaXQgbG9hZGVk Cm5hdGl2ZSBjb21waWxhdGlvbiB1bml0cy4gSWYgaXQgZmluZHMgYSAiLmVsbi5vbGQiIGZpbGUg aXQgd2lsbCB0cnkgdG8KZGVsZXRlIGl0LCBpZiBpdCBmYWlscyB0aGF0IG1lYW5zIHRoYXQgYW5v dGhlciBFbWFjcyBpbnN0YW5jZSBpcyB1c2luZyBpdC4KCldoZW4gY29tcGlsaW5nIGEgZmlsZSB3 ZSByZW5hbWUgdGhlIGZpbGUgdGhhdCB3YXMgaW4gdGhlIG91dHB1dCBwYXRoCmluIGNhc2UgaXQg aGFzIGJlZW4gbG9hZGVkIGludG8gYW5vdGhlciBFbWFjcyBpbnN0YW5jZS4KCldoZW4gZGVsZXRp bmcgYSBwYWNrYWdlIHdlIG1vdmUgYW55ICIuZWxuIiBvciAiLmVsbi5vbGQiIGZpbGVzIGluIHRo ZQpwYWNrYWdlIGZvbGRlciB0aGF0IHdlIGNhbid0IGRlbGV0ZSB0byBgcGFja2FnZS11c2VyLWRp cmAuIEVtYWNzIHdpbGwKY2hlY2sgdGhhdCBkaXJlY3Rvcnkgd2hlbiBjbG9zaW5nIGFuZCBkZWxl dGUgdGhlbS4KCiogbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgKGNvbXAtLXJlcGxhY2Utb3V0cHV0 LWZpbGUpOiBGdW5jdGlvbiBjYWxsZWQKZnJvbSBDIGNvZGUgdG8gZmluaXNoIHRoZSBjb21waWxh dGlvbiBwcm9jZXNzLiBJdCBwZXJmb3JtcyByZW5hbWluZyBvZgp0aGUgb2xkIGZpbGUgaWYgbmVj ZXNzYXJ5LgoqIGxpc3AvZW1hY3MtbGlzcC9wYWNrYWdlLmVsIChwYWNrYWdlLS1kZWxldGUtZGly ZWN0b3J5KTogRnVuY3Rpb24gdG8KZGVsZXRlIGEgcGFja2FnZSBkaXJlY3RvcnkuIEl0IG1vdmVz IG5hdGl2ZSBjb21waWxhdGlvbiB1bml0cyB0aGF0IGl0CmNhbid0IGRlbGV0ZSB0byBgcGFja2Fn ZS11c2VyLWRpcicuCiogc3JjL2FsbG9jLmMgKGNsZWFudXBfdmVjdG9yKTogQ2FsbCBkaXNwb3Nl X2NvbXBfdW5pdCgpLgogIChnYXJiYWdlX2NvbGxlY3QpOiBDYWxsIGZpbmlzaF9kZWxheWVkX2Rp c3Bvc2FsX29mX2NvbXBfdW5pdHMoKS4KKiBzcmMvY29tcC5jOiBSZXN0b3JlIHRoZSBzaWduYWwg bWFzayB1c2luZyB1bndpbmQtcHJvdGVjdC4gU3RvcmUKbG9hZGVkIG5hdGl2ZSBjb21waWxhdGlv biB1bml0cyBpbiBhIGhhc2ggdGFibGUgZm9yIGRpc3Bvc2FsIG9uCmNsb3NlLiBTdG9yZSBmaWxl bmFtZXMgb2YgbmF0aXZlIGNvbXBpbGF0aW9uIHVuaXRzIEdDJ2QgaW4gYSBsaW5rZWQKbGlzdCB0 byBmaW5pc2ggdGhlaXIgZGlzcG9zYWwgd2hlbiB0aGUgR0MgaXMgb3Zlci4KKiBzcmMvY29tcC5o OiBJbnRyb2R1Y2UgY2ZpbGUgbWVtYmVyIGluIExpc3BfTmF0aXZlX0NvbXBfVW5pdC4KQWRkIGRl Y2xhcmF0aW9ucyBvZiBmdW5jdGlvbnMgdGhhdDogY2xlYW4gZGlyZWN0b3JpZXMgb2YgdW51c2Vk IG5hdGl2ZQpjb21waWxhdGlvbiB1bml0cywgaGFuZGxlIGRpc3Bvc2FsIG9mIG5hdGl2ZSBjb21w aWxhdGlvbiB1bml0cy4KKiBzcmMvZW1hY3MuYyAoa2lsbC1lbWFjcyk6IERpc3Bvc2UgYWxsIHJl bWFpbmluZyBjb21waWxhdGlvbiB1bml0cwpyaWdodCByaWdodCBiZWZvcmUgY2FsbGluZyBleGl0 KCkuCiogc3JjL2V2YWwuYyAoaW50ZXJuYWxfY29uZGl0aW9uX2Nhc2VfMywgaW50ZXJuYWxfY29u ZGl0aW9uX2Nhc2VfNCk6CkFkZCBmdW5jdGlvbnMuCiogc3JjL2xpc3AuaCAoaW50ZXJuYWxfY29u ZGl0aW9uX2Nhc2VfMywgaW50ZXJuYWxfY29uZGl0aW9uX2Nhc2VfNCk6CkFkZCBmdW5jdGlvbnMu Ciogc3JjL3BkdW1wZXIuYyAoZHVtcF9kb19kdW1wX3JlbG9jYXRpb24pOiBTZXQgY2ZpbGUgdG8g YSBjb3B5IG9mIHRoZQpMaXNwIHN0cmluZyBzcGVjaWZ5aW5nIHRoZSBmaWxlIHBhdGguCi0tLQog bGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgICAgfCAgMjUgKysrKysrCiBsaXNwL2VtYWNzLWxpc3Av cGFja2FnZS5lbCB8ICAyNyArKysrKy0KIHNyYy9hbGxvYy5jICAgICAgICAgICAgICAgIHwgICA1 ICstCiBzcmMvY29tcC5jICAgICAgICAgICAgICAgICB8IDE3NCArKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLS0tCiBzcmMvY29tcC5oICAgICAgICAgICAgICAgICB8ICAyNyArKysr KysKIHNyYy9lbWFjcy5jICAgICAgICAgICAgICAgIHwgICAzICsKIHNyYy9ldmFsLmMgICAgICAg ICAgICAgICAgIHwgIDU1ICsrKysrKysrKysrKwogc3JjL2xpc3AuaCAgICAgICAgICAgICAgICAg fCAgIDIgKwogc3JjL3BkdW1wZXIuYyAgICAgICAgICAgICAgfCAgIDMgKwogOSBmaWxlcyBjaGFu Z2VkLCAzMDggaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlz cC9lbWFjcy1saXNwL2NvbXAuZWwgYi9saXNwL2VtYWNzLWxpc3AvY29tcC5lbAppbmRleCAyNmJi NzlmY2QxLi5lZTcyYzkyOTkxIDEwMDY0NAotLS0gYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbAor KysgYi9saXNwL2VtYWNzLWxpc3AvY29tcC5lbApAQCAtMjE4Myw2ICsyMTgzLDMxIEBAIGNvbXAt aGludC1jb25zCiAMCiA7OyBTb21lIGVudHJ5IHBvaW50IHN1cHBvcnQgY29kZS4KIAorKGRlZnVu IGNvbXAtLXJlcGxhY2Utb3V0cHV0LWZpbGUgKG91dGZpbGUgdG1wZmlsZSkKKyAgIlJlcGxhY2Ug T1VURklMRSB3aXRoIFRNUEZJTEUgdGFraW5nIHRoZSBuZWNlc3Nhcnkgc3RlcHMgd2hlbgorZGVh bGluZyB3aXRoIHNoYXJlZCBsaWJyYXJpZXMgdGhhdCBtYXkgYmUgbG9hZGVkIGludG8gRW1hY3Mi CisgIChjb25kICgoZXEgJ3dpbmRvd3MtbnQgc3lzdGVtLXR5cGUpCisgICAgICAgICAoaWdub3Jl LWVycm9ycyAoZGVsZXRlLWZpbGUgb3V0ZmlsZSkpCisgICAgICAgICAobGV0ICgocmV0cnkgdCkp CisgICAgICAgICAgICh3aGlsZSByZXRyeQorICAgICAgICAgICAgIChzZXRmIHJldHJ5IG5pbCkK KyAgICAgICAgICAgICAoY29uZGl0aW9uLWNhc2UgXworICAgICAgICAgICAgICAgICAocHJvZ24K KyAgICAgICAgICAgICAgICAgICA7OyBvdXRmaWxlIG1heWJlIHJlY3JlYXRlZCBieSBhbm90aGVy IEVtYWNzIGluCisgICAgICAgICAgICAgICAgICAgOzsgYmV0d2VlbiB0aGUgZm9sbG93aW5nIHR3 byByZW5hbWUtZmlsZSBjYWxscworICAgICAgICAgICAgICAgICAgIChpZiAoZmlsZS1leGlzdHMt cCBvdXRmaWxlKQorICAgICAgICAgICAgICAgICAgICAgICAocmVuYW1lLWZpbGUgb3V0ZmlsZSAo bWFrZS10ZW1wLWZpbGUtaW50ZXJuYWwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIChmaWxlLW5hbWUtc2Fucy1leHRlbnNpb24gb3V0ZmlsZSkKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pbCAiLmVsbi5vbGQiIG5pbCkK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHQpKQorICAgICAgICAgICAgICAg ICAgIChyZW5hbWUtZmlsZSB0bXBmaWxlIG91dGZpbGUgbmlsKSkKKyAgICAgICAgICAgICAgIChm aWxlLWFscmVhZHktZXhpc3RzIChzZXRmIHJldHJ5IHQpKSkpKSkKKyAgICAgICAgOzsgUmVtb3Zl IHRoZSBvbGQgZWxuIGluc3RlYWQgb2YgY29weWluZyB0aGUgbmV3IG9uZSBpbnRvIGl0CisgICAg ICAgIDs7IHRvIGdldCBhIG5ldyBpbm9kZSBhbmQgcHJldmVudCBjcmFzaGVzIGluIGNhc2UgdGhl IG9sZCBvbmUKKyAgICAgICAgOzsgaXMgY3VycmVudGx5IGxvYWRlZC4KKyAgICAgICAgKHQgKGRl bGV0ZS1maWxlIG91dGZpbGUpCisgICAgICAgICAgIChyZW5hbWUtZmlsZSB0bXBmaWxlIG91dGZp bGUpKSkpCisKIChkZWZ2YXIgY29tcC1maWxlcy1xdWV1ZSAoKQogICAiTGlzdCBvZiBFbGlzcCBm aWxlcyB0byBiZSBjb21waWxlZC4iKQogCmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3AvcGFj a2FnZS5lbCBiL2xpc3AvZW1hY3MtbGlzcC9wYWNrYWdlLmVsCmluZGV4IDk1NjU5ODQwYWQuLmMx YzU0YjNjOWEgMTAwNjQ0Ci0tLSBhL2xpc3AvZW1hY3MtbGlzcC9wYWNrYWdlLmVsCisrKyBiL2xp c3AvZW1hY3MtbGlzcC9wYWNrYWdlLmVsCkBAIC0yMTg0LDYgKzIxODQsMzEgQEAgcGFja2FnZS0t bmV3ZXN0LXAKICAgKGVxdWFsIChjYWRyIChhc3NxIChwYWNrYWdlLWRlc2MtbmFtZSBwa2cpIHBh Y2thZ2UtYWxpc3QpKQogICAgICAgICAgcGtnKSkKIAorKGRlZnVuIHBhY2thZ2UtLWRlbGV0ZS1k aXJlY3RvcnkgKGRpcikKKyAgIkRlbGV0ZSBESVIgcmVjdXJzaXZlbHkuCitJbiBXaW5kb3dzIG1v dmUgLmVsbiBhbmQgLmVsbi5vbGQgZmlsZXMgdGhhdCBjYW4gbm90IGJlIGRlbGV0ZWQgdG8gYHBh Y2thZ2UtdXNlci1kaXInLiIKKyAgKGNvbmQgKChlcSAnd2luZG93cy1udCBzeXN0ZW0tdHlwZSkK KyAgICAgICAgIChsZXQgKChyZXRyeSB0KSkKKyAgICAgICAgICAgKHdoaWxlIHJldHJ5CisgICAg ICAgICAgICAgKHNldGYgcmV0cnkgbmlsKQorICAgICAgICAgICAgIChjb25kaXRpb24tY2FzZSBl cnIKKyAgICAgICAgICAgICAgICAgKGRlbGV0ZS1kaXJlY3RvcnkgZGlyIHQpCisgICAgICAgICAg ICAgICAoZmlsZS1lcnJvcgorICAgICAgICAgICAgICAgIChpZiAoYW5kIChzdHJpbmc9ICJSZW1v dmluZyBvbGQgbmFtZSIgKGNhZHIgZXJyKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAoc3Ry aW5nPSAiUGVybWlzc2lvbiBkZW5pZWQiIChjYWRkciBlcnIpKQorICAgICAgICAgICAgICAgICAg ICAgICAgIChvciAoc3RyaW5nLXN1ZmZpeC1wICIuZWxuIiAoY2FkZGRyIGVycikpCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmctc3VmZml4LXAgIi5lbG4ub2xkIiAoY2FkZGRy IGVycikpKSkKKyAgICAgICAgICAgICAgICAgICAgKHByb2duCisgICAgICAgICAgICAgICAgICAg ICAgKHJlbmFtZS1maWxlIChjYWRkZHIgZXJyKQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAobWFrZS10ZW1wLWZpbGUtaW50ZXJuYWwKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIChjb25jYXQgcGFja2FnZS11c2VyLWRpcgorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoZmlsZS1uYW1lLWJhc2UgKGNhZGRkciBlcnIpKSkK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pbCAiLmVsbi5vbGQiIG5pbCkK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdCkKKyAgICAgICAgICAgICAgICAg ICAgICAoc2V0ZiByZXRyeSB0KSkKKyAgICAgICAgICAgICAgICAgIChzaWduYWwgKGNhciBlcnIp IChjZHIgZXJyKSkpKSkpKSkKKyAgICAgICAgKHQgKGRlbGV0ZS1kaXJlY3RvcnkgZGlyIHQpKSkp CisKIChkZWZ1biBwYWNrYWdlLWRlbGV0ZSAocGtnLWRlc2MgJm9wdGlvbmFsIGZvcmNlIG5vc2F2 ZSkKICAgIkRlbGV0ZSBwYWNrYWdlIFBLRy1ERVNDLgogCkBAIC0yMjM2LDcgKzIyNjEsNyBAQCBw YWNrYWdlLWRlbGV0ZQogICAgICAgICAgICAgICAgICAgKHBhY2thZ2UtZGVzYy1uYW1lIHBrZy11 c2VkLWVsc2V3aGVyZS1ieSkpKQogICAgICAgICAgICh0CiAgICAgICAgICAgIChhZGQtaG9vayAn cG9zdC1jb21tYW5kLWhvb2sgIydwYWNrYWdlLW1lbnUtLXBvc3QtcmVmcmVzaCkKLSAgICAgICAg ICAgKGRlbGV0ZS1kaXJlY3RvcnkgZGlyIHQpCisgICAgICAgICAgIChwYWNrYWdlLS1kZWxldGUt ZGlyZWN0b3J5IGRpcikKICAgICAgICAgICAgOzsgUmVtb3ZlIE5BTUUtVkVSU0lPTi5zaWduZWQg YW5kIE5BTUUtcmVhZG1lLnR4dCBmaWxlcy4KICAgICAgICAgICAgOzsKICAgICAgICAgICAgOzsg TkFNRS1yZWFkbWUudHh0IGZpbGVzIGFyZSBubyBsb25nZXIgY3JlYXRlZCwgYnV0IHRoZXkKZGlm ZiAtLWdpdCBhL3NyYy9hbGxvYy5jIGIvc3JjL2FsbG9jLmMKaW5kZXggZjJiODBmYWM4OC4uMTdm NWUxNWIzNSAxMDA2NDQKLS0tIGEvc3JjL2FsbG9jLmMKKysrIGIvc3JjL2FsbG9jLmMKQEAgLTMx MTksOCArMzExOSw3IEBAIGNsZWFudXBfdmVjdG9yIChzdHJ1Y3QgTGlzcF9WZWN0b3IgKnZlY3Rv cikKICAgICB7CiAgICAgICBzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICpjdSA9CiAJUFNF VURPVkVDX1NUUlVDVCAodmVjdG9yLCBMaXNwX05hdGl2ZV9Db21wX1VuaXQpOwotICAgICAgZWFz c2VydCAoY3UtPmhhbmRsZSk7Ci0gICAgICBkeW5saWJfY2xvc2UgKGN1LT5oYW5kbGUpOworICAg ICAgZGlzcG9zZV9jb21wX3VuaXQgKGN1LCB0cnVlKTsKICAgICB9CiB9CiAKQEAgLTYxMTksNiAr NjExOCw4IEBAIGdhcmJhZ2VfY29sbGVjdCAodm9pZCkKICAgICAgIGlmICh0b3RfYWZ0ZXIgPCB0 b3RfYmVmb3JlKQogCW1hbGxvY19wcm9iZSAobWluICh0b3RfYmVmb3JlIC0gdG90X2FmdGVyLCBT SVpFX01BWCkpOwogICAgIH0KKworICBmaW5pc2hfZGVsYXllZF9kaXNwb3NhbF9vZl9jb21wX3Vu aXRzICgpOwogfQogCiBERUZVTiAoImdhcmJhZ2UtY29sbGVjdCIsIEZnYXJiYWdlX2NvbGxlY3Qs IFNnYXJiYWdlX2NvbGxlY3QsIDAsIDAsICIiLApkaWZmIC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3Ny Yy9jb21wLmMKaW5kZXggYjQzZDNlZGRiMy4uMzVlMWVjMGRhMyAxMDA2NDQKLS0tIGEvc3JjL2Nv bXAuYworKysgYi9zcmMvY29tcC5jCkBAIC00MTMsNiArNDEzLDEwIEBAICNkZWZpbmUgVEhJUkQo eCkJCQkJXAogI2RlZmluZSBDQUxMMUkoZnVuLCBhcmcpCQkJCVwKICAgQ0FMTE4gKEZmdW5jYWxs LCBpbnRlcm5fY19zdHJpbmcgKFNUUiAoZnVuKSksIGFyZykKIAorLyogTGlrZSBjYWxsMiBidXQg c3RyaW5naWZ5IGFuZCBpbnRlcm4uICAqLworI2RlZmluZSBDQUxMMkkoZnVuLCBhcmcxLCBhcmcy KQkJCQlcCisgIENBTExOIChGZnVuY2FsbCwgaW50ZXJuX2Nfc3RyaW5nIChTVFIgKGZ1bikpLCBh cmcxLCBhcmcyKQorCiAjZGVmaW5lIERFQ0xfQkxPQ0sobmFtZSwgZnVuYykJCQkJXAogICBnY2Nf aml0X2Jsb2NrICoobmFtZSkgPQkJCQlcCiAgICAgZ2NjX2ppdF9mdW5jdGlvbl9uZXdfYmxvY2sg KChmdW5jKSwgU1RSIChuYW1lKSkKQEAgLTM4MzAsNiArMzgzNCwxNCBAQCBERUZVTiAoImNvbXAt LXJlbGVhc2UtY3R4dCIsIEZjb21wX19yZWxlYXNlX2N0eHQsIFNjb21wX19yZWxlYXNlX2N0eHQs CiAgIHJldHVybiBRdDsKIH0KIAorc2lnc2V0X3Qgb2xkc2V0OworCitzdGF0aWMgdm9pZCByZXN0 b3JlX3NpZ21hc2sodm9pZCkKK3sKKyAgcHRocmVhZF9zaWdtYXNrIChTSUdfU0VUTUFTSywgJm9s ZHNldCwgMCk7CisgIHVuYmxvY2tfaW5wdXQgKCk7Cit9CisKIERFRlVOICgiY29tcC0tY29tcGls ZS1jdHh0LXRvLWZpbGUiLCBGY29tcF9fY29tcGlsZV9jdHh0X3RvX2ZpbGUsCiAgICAgICAgU2Nv bXBfX2NvbXBpbGVfY3R4dF90b19maWxlLAogICAgICAgIDEsIDEsIDAsCkBAIC0zODUxLDYgKzM4 NjMsOCBAQCBERUZVTiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBfX2NvbXBp bGVfY3R4dF90b19maWxlLAogICAgIENBTEwxSSAoY29tcC1kYXRhLWNvbnRhaW5lci1pZHgsIENB TEwxSSAoY29tcC1jdHh0LWQtZXBoZW1lcmFsLCBWY29tcF9jdHh0KSk7CiAKICAgc2lnc2V0X3Qg b2xkc2V0OworICBwdHJkaWZmX3QgY291bnQ7CisKICAgaWYgKCFub25pbnRlcmFjdGl2ZSkKICAg ICB7CiAgICAgICBzaWdzZXRfdCBibG9ja2VkOwpAQCAtMzg2Myw2ICszODc3LDggQEAgREVGVU4g KCJjb21wLS1jb21waWxlLWN0eHQtdG8tZmlsZSIsIEZjb21wX19jb21waWxlX2N0eHRfdG9fZmls ZSwKICAgICAgIHNpZ2FkZHNldCAoJmJsb2NrZWQsIFNJR0lPKTsKICNlbmRpZgogICAgICAgcHRo cmVhZF9zaWdtYXNrIChTSUdfQkxPQ0ssICZibG9ja2VkLCAmb2xkc2V0KTsKKyAgICAgIGNvdW50 ID0gU1BFQ1BETF9JTkRFWCAoKTsKKyAgICAgIHJlY29yZF91bndpbmRfcHJvdGVjdF92b2lkKHJl c3RvcmVfc2lnbWFzayk7CiAgICAgfQogICBlbWl0X2N0eHRfY29kZSAoKTsKIApAQCAtMzkwMiwx OCArMzkxOCwxMCBAQCBERUZVTiAoImNvbXAtLWNvbXBpbGUtY3R4dC10by1maWxlIiwgRmNvbXBf X2NvbXBpbGVfY3R4dF90b19maWxlLAogCQkJCSAgIEdDQ19KSVRfT1VUUFVUX0tJTkRfRFlOQU1J Q19MSUJSQVJZLAogCQkJCSAgIFNTREFUQSAodG1wX2ZpbGUpKTsKIAotICAvKiBSZW1vdmUgdGhl IG9sZCBlbG4gaW5zdGVhZCBvZiBjb3B5aW5nIHRoZSBuZXcgb25lIGludG8gaXQgdG8gZ2V0Ci0g ICAgIGEgbmV3IGlub2RlIGFuZCBwcmV2ZW50IGNyYXNoZXMgaW4gY2FzZSB0aGUgb2xkIG9uZSBp cyBjdXJyZW50bHkKLSAgICAgbG9hZGVkLiAgKi8KLSAgaWYgKCFOSUxQIChGZmlsZV9leGlzdHNf cCAob3V0X2ZpbGUpKSkKLSAgICBGZGVsZXRlX2ZpbGUgKG91dF9maWxlLCBRbmlsKTsKLSAgRnJl bmFtZV9maWxlICh0bXBfZmlsZSwgb3V0X2ZpbGUsIFFuaWwpOworICBDQUxMMkkoY29tcC0tcmVw bGFjZS1vdXRwdXQtZmlsZSwgb3V0X2ZpbGUsIHRtcF9maWxlKTsKIAogICBpZiAoIW5vbmludGVy YWN0aXZlKQotICAgIHsKLSAgICAgIHB0aHJlYWRfc2lnbWFzayAoU0lHX1NFVE1BU0ssICZvbGRz ZXQsIDApOwotICAgICAgdW5ibG9ja19pbnB1dCAoKTsKLSAgICB9CisgICAgdW5iaW5kX3RvKGNv dW50LCBRbmlsKTsKIAogICByZXR1cm4gb3V0X2ZpbGU7CiB9CkBAIC0zOTc0LDYgKzM5ODIsMTM4 IEBAIGhlbHBlcl9QU0VVRE9WRUNUT1JfVFlQRVBfWFVOVEFHIChMaXNwX09iamVjdCBhLCBlbnVt IHB2ZWNfdHlwZSBjb2RlKQogCQkJICAgICBjb2RlKTsKIH0KIAorDAorLyoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKi8KKy8qIERpc3Bvc2FsIG9mIGNvbXBpbGF0aW9uIHVuaXRzICov CisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworCisjaWZkZWYgV0lORE9XU05U CisjZGVmaW5lIE9MRF9FTE5fU1VGRklYX1JFR0VYUCBidWlsZF9zdHJpbmcoIlxcLmVsblxcLm9s ZCQiKQorCitzdGF0aWMgTGlzcF9PYmplY3QgYWxsX2xvYWRlZF9jb21wX3VuaXRzOworCitzdHJ1 Y3QgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWwKK3sKKyAgc3RydWN0IGRlbGF5ZWRfY29tcF91 bml0X2Rpc3Bvc2FsICogbmV4dDsKKyAgY2hhciAqIGZpbGVuYW1lOworfTsKKworc3RydWN0IGRl bGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsICogZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWxfbGlz dDsKKworc3RhdGljIExpc3BfT2JqZWN0CityZXR1cm5RbmlsIChMaXNwX09iamVjdCBhcmcpCit7 CisgIHJldHVybiBRbmlsOworfQorCitzdGF0aWMgdm9pZAorY2xlYW5fY29tcF91bml0X2RpcmVj dG9yeSAoTGlzcF9PYmplY3QgZmlsZXBhdGgpCit7CisgIGlmIChOSUxQIChmaWxlcGF0aCkpCisg ICAgcmV0dXJuOworICBMaXNwX09iamVjdCBmaWxlc19pbl9kaXI7CisgIGZpbGVzX2luX2RpciA9 IGludGVybmFsX2NvbmRpdGlvbl9jYXNlXzQoRmRpcmVjdG9yeV9maWxlcywgZmlsZXBhdGgsIFF0 LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9MRF9FTE5fU1VG RklYX1JFR0VYUCwgUW5pbCwgUXQsIHJldHVyblFuaWwpOworICBGT1JfRUFDSF9UQUlMKGZpbGVz X2luX2RpcikKKyAgICB7CisgICAgICBEZWxldGVGaWxlIChTU0RBVEEgKFhDQVIgKGZpbGVzX2lu X2RpcikpKTsKKyAgICB9Cit9CisKK3ZvaWQgY2xlYW5fcGFja2FnZV91c2VyX2Rpcl9vZl9vbGRf Y29tcF91bml0cyAodm9pZCkKK3sKKyAgTGlzcF9PYmplY3QgcGFja2FnZV91c2VyX2RpciA9IGZp bmRfc3ltYm9sX3ZhbHVlIChpbnRlcm4gKCJwYWNrYWdlLXVzZXItZGlyIikpOworICBpZiAoRVEo cGFja2FnZV91c2VyX2RpciwgUXVuYm91bmQpIHx8ICFTVFJJTkdQKHBhY2thZ2VfdXNlcl9kaXIp KQorICAgIHJldHVybjsKKworICBjbGVhbl9jb21wX3VuaXRfZGlyZWN0b3J5KHBhY2thZ2VfdXNl cl9kaXIpOworfQorCisjZW5kaWYKKwordm9pZCBkaXNwb3NlX2NvbXBfdW5pdCAoc3RydWN0IExp c3BfTmF0aXZlX0NvbXBfVW5pdCAqIGNvbXBfaGFuZGxlLCBib29sIGRlbGF5KQoreworICBlYXNz ZXJ0IChjb21wX2hhbmRsZS0+aGFuZGxlKTsKKyAgZHlubGliX2Nsb3NlIChjb21wX2hhbmRsZS0+ aGFuZGxlKTsKKyNpZmRlZiBXSU5ET1dTTlQKKyAgaWYgKCFkZWxheSkKKyAgICB7CisgICAgICBM aXNwX09iamVjdCBkaXJuYW1lID0gaW50ZXJuYWxfY29uZGl0aW9uX2Nhc2VfMShGZmlsZV9uYW1l X2RpcmVjdG9yeSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJ1aWxkX3N0cmluZyAoY29tcF9oYW5kbGUtPmNmaWxlKSwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFF0LAorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuUW5pbCk7 CisgICAgICBpZiAoIU5JTFAoZGlybmFtZSkpCisgICAgICAgIGNsZWFuX2NvbXBfdW5pdF9kaXJl Y3RvcnkgKGRpcm5hbWUpOworICAgICAgeGZyZWUgKGNvbXBfaGFuZGxlLT5jZmlsZSk7CisgICAg ICBjb21wX2hhbmRsZS0+Y2ZpbGUgPSBOVUxMOworICAgIH0KKyAgZWxzZQorICAgIHsKKyAgICAg IHN0cnVjdCBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbCAqIGhlYWQ7CisgICAgICBoZWFkID0g eG1hbGxvYyAoc2l6ZW9mIChzdHJ1Y3QgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWwpKTsKKyAg ICAgIGhlYWQtPm5leHQgPSBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0OworICAgICAg aGVhZC0+ZmlsZW5hbWUgPSBjb21wX2hhbmRsZS0+Y2ZpbGU7CisgICAgICBjb21wX2hhbmRsZS0+ Y2ZpbGUgPSBOVUxMOworICAgICAgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWxfbGlzdCA9IGhl YWQ7CisgICAgfQorI2Vsc2UKKyAgeGZyZWUgKGNvbXBfaGFuZGxlLT5maWxlKTsKKyNlbmRpZgor fQorCitzdGF0aWMgdm9pZAorcmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCAoTGlzcF9PYmplY3Qg Y29tcF91KQoreworI2lmZGVmIFdJTkRPV1NOVAorICBzdGF0aWMgRU1BQ1NfVUlOVCBjb3VudDsK KworICBpZiAoWEZJWE5VTShGaGFzaF90YWJsZV9jb3VudChhbGxfbG9hZGVkX2NvbXBfdW5pdHMp KSA+PSBNT1NUX1BPU0lUSVZFX0ZJWE5VTSkKKyAgICByZXR1cm47CisKKyAgd2hpbGUgKCFOSUxQ KEZnZXRoYXNoKG1ha2VfZml4bnVtKGNvdW50KSwgYWxsX2xvYWRlZF9jb21wX3VuaXRzLCBRbmls KSkpCisgICAgY291bnQgPSAoY291bnQgKyAxKSAlIE1PU1RfUE9TSVRJVkVfRklYTlVNOworCisg IEZwdXRoYXNoKG1ha2VfZml4bnVtKGNvdW50KSwgY29tcF91LCBhbGxfbG9hZGVkX2NvbXBfdW5p dHMpOworI2VuZGlmCit9CisKK3ZvaWQgZGlzcG9zZV9hbGxfcmVtYWluaW5nX2NvbXBfdW5pdHMg KHZvaWQpCit7CisjaWZkZWYgV0lORE9XU05UCisgIHN0cnVjdCBMaXNwX0hhc2hfVGFibGUgKmgg PSBYSEFTSF9UQUJMRSAoYWxsX2xvYWRlZF9jb21wX3VuaXRzKTsKKworICBmb3IgKHB0cmRpZmZf dCBpID0gMDsgaSA8IEhBU0hfVEFCTEVfU0laRSAoaCk7ICsraSkKKyAgICB7CisgICAgICBMaXNw X09iamVjdCBrID0gSEFTSF9LRVkgKGgsIGkpOworICAgICAgaWYgKCFFUSAoaywgUXVuYm91bmQp KQorICAgICAgICB7CisgICAgICAgICAgTGlzcF9PYmplY3QgdmFsID0gSEFTSF9WQUxVRSAoaCwg aSk7CisgICAgICAgICAgc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqIGN1ID0gWE5BVElW RV9DT01QX1VOSVQodmFsKTsKKyAgICAgICAgICBkaXNwb3NlX2NvbXBfdW5pdChjdSwgZmFsc2Up OworICAgICAgICB9CisgICAgfQorI2VuZGlmCit9CisKK3ZvaWQgZmluaXNoX2RlbGF5ZWRfZGlz cG9zYWxfb2ZfY29tcF91bml0cyAodm9pZCkKK3sKKyNpZmRlZiBXSU5ET1dTTlQKKyAgZm9yIChz dHJ1Y3QgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9zYWwgKiBpdGVtID0gZGVsYXllZF9jb21wX3Vu aXRfZGlzcG9zYWxfbGlzdDsKKyAgICAgICBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0 OworICAgICAgIGl0ZW0gPSBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0KQorICAgIHsK KyAgICAgIGRlbGF5ZWRfY29tcF91bml0X2Rpc3Bvc2FsX2xpc3QgPSBpdGVtLT5uZXh0OworICAg ICAgTGlzcF9PYmplY3QgZGlybmFtZQorICAgICAgICA9IGludGVybmFsX2NvbmRpdGlvbl9jYXNl XzEgKEZmaWxlX25hbWVfZGlyZWN0b3J5LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGJ1aWxkX3N0cmluZyAoaXRlbS0+ZmlsZW5hbWUpLCBRdCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZXR1cm5RbmlsKTsKKyAgICAgIGNsZWFuX2NvbXBfdW5p dF9kaXJlY3RvcnkgKGRpcm5hbWUpOworICAgICAgeGZyZWUoaXRlbS0+ZmlsZW5hbWUpOworICAg ICAgeGZyZWUoaXRlbSk7CisgICAgfQorI2VuZGlmCit9CisKIAwKIC8qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKi8KIC8qIERlZmVycmVkIGNvbXBpbGF0aW9uIG1lY2hhbmlzbS4g Ki8KQEAgLTQxNjAsNiArNDMwMCwxMiBAQCBsb2FkX2NvbXBfdW5pdCAoc3RydWN0IExpc3BfTmF0 aXZlX0NvbXBfVW5pdCAqY29tcF91LCBib29sIGxvYWRpbmdfZHVtcCwKICAgICAgIGRfdmVjX2xl biA9IFhGSVhOVU0gKEZsZW5ndGggKGNvbXBfdS0+ZGF0YV9pbXB1cmVfdmVjKSk7CiAgICAgICBm b3IgKEVNQUNTX0lOVCBpID0gMDsgaSA8IGRfdmVjX2xlbjsgaSsrKQogCWRhdGFfaW1wX3JlbG9j c1tpXSA9IEFSRUYgKGNvbXBfdS0+ZGF0YV9pbXB1cmVfdmVjLCBpKTsKKworICAgICAgLyogSWYg d2UgcmVnaXN0ZXIgdGhlbSB3aGlsZSBkdW1waW5nIHdlIHdpbGwgZ2V0IHNvbWUgZW50cmllcyBp bgorICAgICAgICAgdGhlIGhhc2ggdGFibGUgdGhhdCB3aWxsIGJlIGR1cGxpY2F0ZWQgd2hlbiBw ZHVtcGVyIGNhbGxzCisgICAgICAgICBsb2FkX2NvbXBfdW5pdC4gKi8KKyAgICAgIGlmICghd2ls bF9kdW1wX3AoKSkKKyAgICAgICAgcmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCAoY29tcF91X2xp c3Bfb2JqKTsKICAgICB9CiAKICAgaWYgKCFsb2FkaW5nX2R1bXApCkBAIC00MjczLDYgKzQ0MTks OSBAQCBERUZVTiAoIm5hdGl2ZS1lbGlzcC1sb2FkIiwgRm5hdGl2ZV9lbGlzcF9sb2FkLCBTbmF0 aXZlX2VsaXNwX2xvYWQsIDEsIDIsIDAsCiAgIGlmICghY29tcF91LT5oYW5kbGUpCiAgICAgeHNp Z25hbDIgKFFuYXRpdmVfbGlzcF9sb2FkX2ZhaWxlZCwgZmlsZSwgYnVpbGRfc3RyaW5nIChkeW5s aWJfZXJyb3IgKCkpKTsKICAgY29tcF91LT5maWxlID0gZmlsZTsKKyNpZmRlZiBXSU5ET1dTTlQK KyAgY29tcF91LT5jZmlsZSA9IHhsaXNwc3RyZHVwKGZpbGUpOworI2VuZGlmCiAgIGNvbXBfdS0+ ZGF0YV92ZWMgPSBRbmlsOwogICBsb2FkX2NvbXBfdW5pdCAoY29tcF91LCBmYWxzZSwgIU5JTFAg KGxhdGVfbG9hZCkpOwogCkBAIC00NDE3LDYgKzQ1NjYsMTEgQEAgc3ltc19vZl9jb21wICh2b2lk KQogICBzdGF0aWNwcm8gKCZkZWxheWVkX3NvdXJjZXMpOwogICBkZWxheWVkX3NvdXJjZXMgPSBR bmlsOwogCisjaWZkZWYgV0lORE9XU05UCisgIHN0YXRpY3BybyAoJmFsbF9sb2FkZWRfY29tcF91 bml0cyk7CisgIGFsbF9sb2FkZWRfY29tcF91bml0cyA9IENBTExOKEZtYWtlX2hhc2hfdGFibGUs IFFDd2Vha25lc3MsIFF2YWx1ZSk7CisjZW5kaWYKKwogICBERUZWQVJfTElTUCAoImNvbXAtY3R4 dCIsIFZjb21wX2N0eHQsCiAJICAgICAgIGRvYzogLyogVGhlIGNvbXBpbGVyIGNvbnRleHQuICAq Lyk7CiAgIFZjb21wX2N0eHQgPSBRbmlsOwpkaWZmIC0tZ2l0IGEvc3JjL2NvbXAuaCBiL3NyYy9j b21wLmgKaW5kZXggZTZhYjMyZmY4ZS4uODllZjc0MGZlNiAxMDA2NDQKLS0tIGEvc3JjL2NvbXAu aAorKysgYi9zcmMvY29tcC5oCkBAIC00NCw3ICs0NCwxNSBAQCAjZGVmaW5lIENPTVBfSAogICAv KiBTYW1lIGJ1dCBmb3IgZGF0YSB0aGF0IGNhbm5vdCBiZSBtb3ZlZCB0byBwdXJlIHNwYWNlLgog ICAgICBNdXN0IGJlIHRoZSBsYXN0IGxpc3Agb2JqZWN0IGhlcmUuICAgKi8KICAgTGlzcF9PYmpl Y3QgZGF0YV9pbXB1cmVfdmVjOworCiAgIGR5bmxpYl9oYW5kbGVfcHRyIGhhbmRsZTsKKyNpZmRl ZiBXSU5ET1dTTlQKKyAgLyogV2UgbmVlZCB0byBzdG9yZSBhIGNvcHkgb2YgdGhlIG9yaWdpbmFs IGZpbGUgbmFtZSBpbiBtZW1vcnkgdGhhdAorICAgICBpcyBub3Qgc3ViamVjdCB0byBHQyBiZWNh dXNlIHRoZSBmdW5jdGlvbiB0byBkaXNwb3NlIG5hdGl2ZQorICAgICBjb21waWxhdGlvbiB1bml0 cyBpcyBjYWxsZWQgYnkgdGhlIEdDLiBCeSB0aGF0IHRpbWUgdGhlIGBmaWxlJworICAgICBzdHJp bmcgbWF5IGhhdmUgYmVlbiBzd2VlcGVkLiAqLworICBjaGFyICogY2ZpbGU7CisjZW5kaWYKIH07 CiAKICNpZmRlZiBIQVZFX05BVElWRV9DT01QCkBAIC03NSw2ICs4MywxNCBAQCBYTkFUSVZFX0NP TVBfVU5JVCAoTGlzcF9PYmplY3QgYSkKIAogZXh0ZXJuIHZvaWQgbWF5YmVfZGVmZXJfbmF0aXZl X2NvbXBpbGF0aW9uIChMaXNwX09iamVjdCBmdW5jdGlvbl9uYW1lLAogCQkJCQkgICAgTGlzcF9P YmplY3QgZGVmaW5pdGlvbik7CisKK2V4dGVybiB2b2lkIGRpc3Bvc2VfY29tcF91bml0IChzdHJ1 Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICogY29tcF91bml0LCBib29sIGRlbGF5KTsKKworZXh0 ZXJuIHZvaWQgZmluaXNoX2RlbGF5ZWRfZGlzcG9zYWxfb2ZfY29tcF91bml0cyAodm9pZCk7CisK K2V4dGVybiB2b2lkIGRpc3Bvc2VfYWxsX3JlbWFpbmluZ19jb21wX3VuaXRzICh2b2lkKTsKKwor ZXh0ZXJuIHZvaWQgY2xlYW5fcGFja2FnZV91c2VyX2Rpcl9vZl9vbGRfY29tcF91bml0cyAodm9p ZCk7CiAjZWxzZQogCiBzdGF0aWMgaW5saW5lIHZvaWQKQEAgLTg0LDYgKzEwMCwxNyBAQCBtYXli ZV9kZWZlcl9uYXRpdmVfY29tcGlsYXRpb24gKExpc3BfT2JqZWN0IGZ1bmN0aW9uX25hbWUsCiAK IGV4dGVybiB2b2lkIHN5bXNfb2ZfY29tcCAodm9pZCk7CiAKK3N0YXRpYyBpbmxpbmUgdm9pZCBk aXNwb3NlX2NvbXBfdW5pdCAoc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqIGNvbXBfaGFu ZGxlKQoreworICBlbWFjc19hYm9ydCgpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQgZGlzcG9z ZV9hbGxfcmVtYWluaW5nX2NvbXBfdW5pdHMgKHZvaWQpCit7fQorCitzdGF0aWMgaW5saW5lIHZv aWQgY2xlYW5fcGFja2FnZV91c2VyX2Rpcl9vZl9vbGRfY29tcF91bml0cyAodm9pZCkKK3t9CisK ICNlbmRpZgogCiAjZW5kaWYKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy5jIGIvc3JjL2VtYWNzLmMK aW5kZXggZTc1Y2I1ODgzNC4uYjdjODliNDRlYyAxMDA2NDQKLS0tIGEvc3JjL2VtYWNzLmMKKysr IGIvc3JjL2VtYWNzLmMKQEAgLTIzOTMsNiArMjM5Myw5IEBAIERFRlVOICgia2lsbC1lbWFjcyIs IEZraWxsX2VtYWNzLCBTa2lsbF9lbWFjcywgMCwgMSwgIlAiLAogICAgICAgdW5saW5rIChTU0RB VEEgKGxpc3RmaWxlKSk7CiAgICAgfQogCisgIGRpc3Bvc2VfYWxsX3JlbWFpbmluZ19jb21wX3Vu aXRzKCk7CisgIGNsZWFuX3BhY2thZ2VfdXNlcl9kaXJfb2Zfb2xkX2NvbXBfdW5pdHMoKTsKKwog ICBpZiAoRklYTlVNUCAoYXJnKSkKICAgICBleGl0X2NvZGUgPSAoWEZJWE5VTSAoYXJnKSA8IDAK IAkJID8gWEZJWE5VTSAoYXJnKSB8IElOVF9NSU4KZGlmZiAtLWdpdCBhL3NyYy9ldmFsLmMgYi9z cmMvZXZhbC5jCmluZGV4IDEwOTFiMDgyNTUuLmE2OGZjOTAyODUgMTAwNjQ0Ci0tLSBhL3NyYy9l dmFsLmMKKysrIGIvc3JjL2V2YWwuYwpAQCAtMTQxOSw2ICsxNDE5LDYxIEBAIGludGVybmFsX2Nv bmRpdGlvbl9jYXNlXzIgKExpc3BfT2JqZWN0ICgqYmZ1bikgKExpc3BfT2JqZWN0LCBMaXNwX09i amVjdCksCiAgICAgfQogfQogCisvKiBMaWtlIGludGVybmFsX2NvbmRpdGlvbl9jYXNlXzEgYnV0 IGNhbGwgQkZVTiB3aXRoIEFSRzEsIEFSRzIsIEFSRzMgYXMKKyAgIGl0cyBhcmd1bWVudHMuICAq LworCitMaXNwX09iamVjdAoraW50ZXJuYWxfY29uZGl0aW9uX2Nhc2VfMyAoTGlzcF9PYmplY3Qg KCpiZnVuKSAoTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LAorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlzcF9PYmplY3QpLAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgTGlzcF9PYmplY3QgYXJnMSwgTGlzcF9PYmplY3QgYXJnMiwgTGlzcF9PYmpl Y3QgYXJnMywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIExpc3BfT2JqZWN0IGhhbmRsZXJz LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlzcF9PYmplY3QgKCpoZnVuKSAoTGlzcF9P YmplY3QpKQoreworICBzdHJ1Y3QgaGFuZGxlciAqYyA9IHB1c2hfaGFuZGxlciAoaGFuZGxlcnMs IENPTkRJVElPTl9DQVNFKTsKKyAgaWYgKHN5c19zZXRqbXAgKGMtPmptcCkpCisgICAgeworICAg ICAgTGlzcF9PYmplY3QgdmFsID0gaGFuZGxlcmxpc3QtPnZhbDsKKyAgICAgIGNsb2JiZXJlZF9l YXNzZXJ0IChoYW5kbGVybGlzdCA9PSBjKTsKKyAgICAgIGhhbmRsZXJsaXN0ID0gaGFuZGxlcmxp c3QtPm5leHQ7CisgICAgICByZXR1cm4gaGZ1biAodmFsKTsKKyAgICB9CisgIGVsc2UKKyAgICB7 CisgICAgICBMaXNwX09iamVjdCB2YWwgPSBiZnVuIChhcmcxLCBhcmcyLCBhcmczKTsKKyAgICAg IGVhc3NlcnQgKGhhbmRsZXJsaXN0ID09IGMpOworICAgICAgaGFuZGxlcmxpc3QgPSBjLT5uZXh0 OworICAgICAgcmV0dXJuIHZhbDsKKyAgICB9Cit9CisKKy8qIExpa2UgaW50ZXJuYWxfY29uZGl0 aW9uX2Nhc2VfMSBidXQgY2FsbCBCRlVOIHdpdGggQVJHMSwgQVJHMiwgQVJHMywgQVJHNCBhcwor ICAgaXRzIGFyZ3VtZW50cy4gICovCisKK0xpc3BfT2JqZWN0CitpbnRlcm5hbF9jb25kaXRpb25f Y2FzZV80IChMaXNwX09iamVjdCAoKmJmdW4pIChMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMaXNwX09iamVj dCwgTGlzcF9PYmplY3QpLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlzcF9PYmplY3Qg YXJnMSwgTGlzcF9PYmplY3QgYXJnMiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIExpc3Bf T2JqZWN0IGFyZzMsIExpc3BfT2JqZWN0IGFyZzQsCisgICAgICAgICAgICAgICAgICAgICAgICAg ICBMaXNwX09iamVjdCBoYW5kbGVycywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIExpc3Bf T2JqZWN0ICgqaGZ1bikgKExpc3BfT2JqZWN0KSkKK3sKKyAgc3RydWN0IGhhbmRsZXIgKmMgPSBw dXNoX2hhbmRsZXIgKGhhbmRsZXJzLCBDT05ESVRJT05fQ0FTRSk7CisgIGlmIChzeXNfc2V0am1w IChjLT5qbXApKQorICAgIHsKKyAgICAgIExpc3BfT2JqZWN0IHZhbCA9IGhhbmRsZXJsaXN0LT52 YWw7CisgICAgICBjbG9iYmVyZWRfZWFzc2VydCAoaGFuZGxlcmxpc3QgPT0gYyk7CisgICAgICBo YW5kbGVybGlzdCA9IGhhbmRsZXJsaXN0LT5uZXh0OworICAgICAgcmV0dXJuIGhmdW4gKHZhbCk7 CisgICAgfQorICBlbHNlCisgICAgeworICAgICAgTGlzcF9PYmplY3QgdmFsID0gYmZ1biAoYXJn MSwgYXJnMiwgYXJnMywgYXJnNCk7CisgICAgICBlYXNzZXJ0IChoYW5kbGVybGlzdCA9PSBjKTsK KyAgICAgIGhhbmRsZXJsaXN0ID0gYy0+bmV4dDsKKyAgICAgIHJldHVybiB2YWw7CisgICAgfQor fQorCiAvKiBMaWtlIGludGVybmFsX2NvbmRpdGlvbl9jYXNlIGJ1dCBjYWxsIEJGVU4gd2l0aCBO QVJHUyBhcyBmaXJzdCwKICAgIGFuZCBBUkdTIGFzIHNlY29uZCBhcmd1bWVudC4gICovCiAKZGlm ZiAtLWdpdCBhL3NyYy9saXNwLmggYi9zcmMvbGlzcC5oCmluZGV4IGUyNDI1NDZkMTAuLmVlYWMy MDU5OGMgMTAwNjQ0Ci0tLSBhL3NyYy9saXNwLmgKKysrIGIvc3JjL2xpc3AuaApAQCAtNDEzOCw2 ICs0MTM4LDggQEAgeHNpZ25hbCAoTGlzcF9PYmplY3QgZXJyb3Jfc3ltYm9sLCBMaXNwX09iamVj dCBkYXRhKQogZXh0ZXJuIExpc3BfT2JqZWN0IGludGVybmFsX2NvbmRpdGlvbl9jYXNlIChMaXNw X09iamVjdCAoKikgKHZvaWQpLCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QgKCopIChMaXNwX09i amVjdCkpOwogZXh0ZXJuIExpc3BfT2JqZWN0IGludGVybmFsX2NvbmRpdGlvbl9jYXNlXzEgKExp c3BfT2JqZWN0ICgqKSAoTGlzcF9PYmplY3QpLCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExp c3BfT2JqZWN0ICgqKSAoTGlzcF9PYmplY3QpKTsKIGV4dGVybiBMaXNwX09iamVjdCBpbnRlcm5h bF9jb25kaXRpb25fY2FzZV8yIChMaXNwX09iamVjdCAoKikgKExpc3BfT2JqZWN0LCBMaXNwX09i amVjdCksIExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0 ICgqKSAoTGlzcF9PYmplY3QpKTsKK2V4dGVybiBMaXNwX09iamVjdCBpbnRlcm5hbF9jb25kaXRp b25fY2FzZV8zIChMaXNwX09iamVjdCAoKikgKExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgTGlz cF9PYmplY3QpLCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09i amVjdCwgTGlzcF9PYmplY3QgKCopIChMaXNwX09iamVjdCkpOworZXh0ZXJuIExpc3BfT2JqZWN0 IGludGVybmFsX2NvbmRpdGlvbl9jYXNlXzQgKExpc3BfT2JqZWN0ICgqKSAoTGlzcF9PYmplY3Qs IExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QpLCBMaXNwX09iamVjdCwgTGlz cF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsIExpc3BfT2Jq ZWN0ICgqKSAoTGlzcF9PYmplY3QpKTsKIGV4dGVybiBMaXNwX09iamVjdCBpbnRlcm5hbF9jb25k aXRpb25fY2FzZV9uCiAgICAgKExpc3BfT2JqZWN0ICgqKSAocHRyZGlmZl90LCBMaXNwX09iamVj dCAqKSwgcHRyZGlmZl90LCBMaXNwX09iamVjdCAqLAogICAgICBMaXNwX09iamVjdCwgTGlzcF9P YmplY3QgKCopIChMaXNwX09iamVjdCwgcHRyZGlmZl90LCBMaXNwX09iamVjdCAqKSk7CmRpZmYg LS1naXQgYS9zcmMvcGR1bXBlci5jIGIvc3JjL3BkdW1wZXIuYwppbmRleCBmODM3ZGZjMzhkLi45 YjBiZDQ3MmQ2IDEwMDY0NAotLS0gYS9zcmMvcGR1bXBlci5jCisrKyBiL3NyYy9wZHVtcGVyLmMK QEAgLTUzMTIsNiArNTMxMiw5IEBAIGR1bXBfZG9fZHVtcF9yZWxvY2F0aW9uIChjb25zdCB1aW50 cHRyX3QgZHVtcF9iYXNlLAogCSAgY29uY2F0MiAoVmludm9jYXRpb25fZGlyZWN0b3J5LAogCQkg ICBpbnN0YWxsYXRpb25fc3RhdGUgPT0gTE9DQUxfQlVJTEQKIAkJICAgPyBYQ0RSIChjb21wX3Ut PmZpbGUpIDogWENBUiAoY29tcF91LT5maWxlKSk7CisjaWZkZWYgV0lORE9XU05UCisgICAgICAg IGNvbXBfdS0+Y2ZpbGUgPSB4bGlzcHN0cmR1cChjb21wX3UtPmZpbGUpOworI2VuZGlmCiAJY29t cF91LT5oYW5kbGUgPSBkeW5saWJfb3BlbiAoU1NEQVRBIChjb21wX3UtPmZpbGUpKTsKIAlpZiAo IWNvbXBfdS0+aGFuZGxlKQogCSAgZXJyb3IgKCIlcyIsIGR5bmxpYl9lcnJvciAoKSk7Ci0tIAoy LjI1LjEud2luZG93cy4xCgo= --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0007-Load-libgccjit-dynamically-in-Windows.patch" Content-Disposition: attachment; filename="0007-Load-libgccjit-dynamically-in-Windows.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5vc6 RnJvbSA2ZjViYzdhNWUyYTBhNGVmNTI1OGFiMjQ2YjM4NzM5NmNjMTcyM2RlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAxMSBNYXkgMjAyMCAyMDo0 MzowNiAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggNy85XSBMb2FkIGxpYmdjY2ppdCBkeW5hbWljYWxs eSBpbiBXaW5kb3dzLgoKKiBjb25maWd1cmUuYWM6IGRvbid0IGFkZCBsaW5rZXIgZmxhZ3MgaWYg Y29tcGlsaW5nIG9uCldpbmRvd3MuIENvbXBpbGUgZHlubGliLmMgaWYgbW9kdWxlcyBvciBuYXRp dmUgY29tcGlsYXRpb24gYXJlCmVuYWJsZWQuIEFsd2F5cyBjb21waWxlIGNvbXAuYwoqIGxpc3Av dGVybS93MzItd2luLmVsOiBNYXAgJ2djY2ppdCB0byAibGliZ2Njaml0LmRsbCIgaW4KYGR5bmFt aWMtbGlicmFyeS1hbGlzdGAuCiogc3JjL01ha2VmaWxlLmluOiBVcGRhdGUgY29tbWVudHMuIFVw ZGF0ZSB0byBoYW5kbGUgY2hhbmdlcyBpbgpjb25maWd1cmUuYWMuCiogc3JjL2NvbXAuYzogQWRk IGRlY2xhcmF0aW9ucyBvZiB1c2VkIGxpYmdjY2ppdCBmdW5jdGlvbnMgdXNpbmcKREVGX0RMTF9G Ti4gQWRkIGNhbGxzIHRvIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSgpIHdoZXJlIG5lY2Vzc2Fy eS4KQWRkIGBuYXRpdmUtY29tcC1hdmFpbGFibGUtcGAKKiBzcmMvY29tcC5oOiBSZW1vdmUgRm5h dGl2ZV9lbGlzcF9sb2FkLiBBZGQgc3ltc19vZl9jb21wKCkuCiogc3JjL2VtYWNzLmMgKG1haW4p OiBBbHdheXMgY2FsbCBzeW1zX29mX2NvbXAoKQoqIHNyYy93MzIuYyAoZ2xvYmFsc19vZl93MzIp OiBDbGVhciBWbGlicmFyeV9jYWNoZSB3aGVuIHN0YXJ0aW5nCmJlY2F1c2UgdGhlIGxpYnJhcmll cyBsb2FkZWQgd2hlbiBkdW1waW5nIHdpbGwgbm90IGJlIGxvYWRlZCB3aGVuCnN0YXJ0aW5nLgoq IHNyYy93MzJmbnMuYzogQWRkIFFnY2NqaXQgc3ltYm9sLgotLS0KIGNvbmZpZ3VyZS5hYyAgICAg ICAgIHwgIDE5ICsrLQogbGlzcC90ZXJtL3czMi13aW4uZWwgfCAgIDMgKy0KIHNyYy9NYWtlZmls ZS5pbiAgICAgIHwgICA5ICstCiBzcmMvY29tcC5jICAgICAgICAgICB8IDM3NCArKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBzcmMvY29tcC5oICAgICAgICAgICB8 ICAgNiArLQogc3JjL2VtYWNzLmMgICAgICAgICAgfCAgIDIgLQogc3JjL3czMi5jICAgICAgICAg ICAgfCAgIDQgKwogc3JjL3czMmZucy5jICAgICAgICAgfCAgIDEgKwogOCBmaWxlcyBjaGFuZ2Vk LCAzOTggaW5zZXJ0aW9ucygrKSwgMjAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvY29uZmln dXJlLmFjIGIvY29uZmlndXJlLmFjCmluZGV4IDIzYjk0Y2Y2Y2EuLmVhMDE0NGY0MDQgMTAwNjQ0 Ci0tLSBhL2NvbmZpZ3VyZS5hYworKysgYi9jb25maWd1cmUuYWMKQEAgLTM2NjYsNiArMzY2Niw3 IEBAIEFDX0RFRlVOCiBMSUJNT0RVTEVTPQogSEFWRV9NT0RVTEVTPW5vCiBNT0RVTEVTX09CSj0K K05FRURfRFlOTElCPW5vCiBjYXNlICRvcHN5cyBpbgogICBjeWd3aW58bWluZ3czMikgTU9EVUxF U19TVUZGSVg9Ii5kbGwiIDs7CiAgIGRhcndpbikgTU9EVUxFU19TVUZGSVg9Ii5keWxpYiIgOzsK QEAgLTM3MDEsNyArMzcwMiw4IEBAIEFDX0RFRlVOCiBmaQogCiBpZiB0ZXN0ICIke0hBVkVfTU9E VUxFU30iID0geWVzOyB0aGVuCi0gICBNT0RVTEVTX09CSj0iZHlubGliLm8gZW1hY3MtbW9kdWxl Lm8iCisgICBNT0RVTEVTX09CSj0iZW1hY3MtbW9kdWxlLm8iCisgICBORUVEX0RZTkxJQj15ZXMK ICAgIEFDX0RFRklORShIQVZFX01PRFVMRVMsIDEsIFtEZWZpbmUgdG8gMSBpZiBkeW5hbWljIG1v ZHVsZXMgYXJlIGVuYWJsZWRdKQogICAgQUNfREVGSU5FX1VOUVVPVEVEKE1PRFVMRVNfU1VGRklY LCAiJE1PRFVMRVNfU1VGRklYIiwKICAgICAgW1N5c3RlbSBleHRlbnNpb24gZm9yIGR5bmFtaWMg bGlicmFyaWVzXSkKQEAgLTM3ODUsNyArMzc4Nyw2IEBAIEFDX0RFRlVOCiAKIEhBVkVfTkFUSVZF X0NPTVA9bm8KIExJQkdDQ0pJVF9MSUI9Ci1DT01QX09CSj0KIGlmIHRlc3QgIiR7d2l0aF9uYXRp dmVjb21wfSIgIT0gIm5vIjsgdGhlbgogICAgIGVtYWNzX3NhdmVfTElCUz0kTElCUwogICAgIExJ QlM9Ii1sZ2Njaml0IgpAQCAtMzc5Myw4ICszNzk0LDExIEBAIEFDX0RFRlVOCiAgICAgICBbQUNf TElOS19JRkVMU0UoW2xpYmdjY2ppdF9zbW9rZV90ZXN0XSwgW10sIFtsaWJnY2NqaXRfbm90X2Zv dW5kXSldKQogICAgIExJQlM9JGVtYWNzX3NhdmVfTElCUwogICAgIEhBVkVfTkFUSVZFX0NPTVA9 eWVzCi0gICAgTElCR0NDSklUX0xJQj0iLWxnY2NqaXQgLWxkbCIKLSAgICBDT01QX09CSj0iY29t cC5vIgorICAgICMgbWluZ3czMiBsb2FkcyB0aGUgbGlicmFyeSBkeW5hbWljYWxseS4KKyAgICBp ZiB0ZXN0ICIke29wc3lzfSIgIT0gIm1pbmd3MzIiOyB0aGVuCisgICAgICBMSUJHQ0NKSVRfTElC PSItbGdjY2ppdCAtbGRsIgorICAgIGZpCisgICAgTkVFRF9EWU5MSUI9eWVzCiAgICAgQUNfREVG SU5FKEhBVkVfTkFUSVZFX0NPTVAsIDEsIFtEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgbGli Z2Njaml0IGxpYnJhcnkgKC1sZ2Njaml0KS5dKQogZmkKIGlmIHRlc3QgIiR7SEFWRV9OQVRJVkVf Q09NUH0iID0geWVzICYmIHRlc3QgIiR7SEFWRV9QRFVNUEVSfSIgPSBubzsgdGhlbgpAQCAtMzgw NCw3ICszODA4LDEyIEBAIEFDX0RFRlVOCiAgIFtTeXN0ZW0gZXh0ZW5zaW9uIGZvciBuYXRpdmUg Y29tcGlsZWQgZWxpc3BdKQogQUNfU1VCU1QoSEFWRV9OQVRJVkVfQ09NUCkKIEFDX1NVQlNUKExJ QkdDQ0pJVF9MSUIpCi1BQ19TVUJTVChDT01QX09CSikKKworRFlOTElCX09CSj0KK2lmIHRlc3Qg IiR7TkVFRF9EWU5MSUJ9IiA9IHllczsgdGhlbgorICBEWU5MSUJfT0JKPSJkeW5saWIubyIKK2Zp CitBQ19TVUJTVChEWU5MSUJfT0JKKQogCiAjIyMgVXNlIC1scG5nIGlmIGF2YWlsYWJsZSwgdW5s ZXNzICctLXdpdGgtcG5nPW5vJy4KIEhBVkVfUE5HPW5vCmRpZmYgLS1naXQgYS9saXNwL3Rlcm0v dzMyLXdpbi5lbCBiL2xpc3AvdGVybS93MzItd2luLmVsCmluZGV4IDU5MDFlMDI5NWUuLjZiOTcx NmNhMzAgMTAwNjQ0Ci0tLSBhL2xpc3AvdGVybS93MzItd2luLmVsCisrKyBiL2xpc3AvdGVybS93 MzItd2luLmVsCkBAIC0yODksNyArMjg5LDggQEAgbGliZ251dGxzLXZlcnNpb24KICAgICAgICAn KGxpYnhtbDIgImxpYnhtbDItMi5kbGwiICJsaWJ4bWwyLmRsbCIpCiAgICAgICAgJyh6bGliICJ6 bGliMS5kbGwiICJsaWJ6LTEuZGxsIikKICAgICAgICAnKGxjbXMyICJsaWJsY21zMi0yLmRsbCIp Ci0gICAgICAgJyhqc29uICJsaWJqYW5zc29uLTQuZGxsIikpKQorICAgICAgICcoanNvbiAibGli amFuc3Nvbi00LmRsbCIpCisgICAgICAgJyhnY2NqaXQgImxpYmdjY2ppdC5kbGwiKSkpCiAKIDs7 OyBtdWx0aS10dHkgc3VwcG9ydAogKGRlZnZhciB3MzItaW5pdGlhbGl6ZWQgbmlsCmRpZmYgLS1n aXQgYS9zcmMvTWFrZWZpbGUuaW4gYi9zcmMvTWFrZWZpbGUuaW4KaW5kZXggNjNmOTA5YWUxNC4u ODU3MDkxODRkYSAxMDA2NDQKLS0tIGEvc3JjL01ha2VmaWxlLmluCisrKyBiL3NyYy9NYWtlZmls ZS5pbgpAQCAtMjQxLDcgKzI0MSw3IEBAIExJQlogPQogCiAjIyBzeXN0ZW0tc3BlY2lmaWMgbGli cyBmb3IgZHluYW1pYyBtb2R1bGVzLCBlbHNlIGVtcHR5CiBMSUJNT0RVTEVTID0gQExJQk1PRFVM RVNACi0jIyBkeW5saWIubyBlbWFjcy1tb2R1bGUubyBpZiBtb2R1bGVzIGVuYWJsZWQsIGVsc2Ug ZW1wdHkKKyMjIGVtYWNzLW1vZHVsZS5vIGlmIG1vZHVsZXMgZW5hYmxlZCwgZWxzZSBlbXB0eQog TU9EVUxFU19PQkogPSBATU9EVUxFU19PQkpACiAKIFhSQU5EUl9MSUJTID0gQFhSQU5EUl9MSUJT QApAQCAtMzI3LDggKzMyNyw5IEBAIEdNUF9MSUIgPQogR01QX09CSiA9IEBHTVBfT0JKQAogCiBM SUJHQ0NKSVQgPSBATElCR0NDSklUX0xJQkAKLSMjIGR5bmxpYi5vIGNvbXAubyBpZiBuYXRpdmUg Y29tcGlsZXIgaXMgZW5hYmxlZCwgb3RoZXJ3aXNlIGVtcHR5LgotQ09NUF9PQkogPSBAQ09NUF9P QkpACisKKyMjIGR5bmxpYi5vIGlmIG5lY2Vzc2FyeSwgZWxzZSBlbXB0eQorRFlOTElCX09CSiA9 IEBEWU5MSUJfT0JKQAogCiBSVU5fVEVNQUNTID0gLi90ZW1hY3MKIApAQCAtNDE4LDcgKzQxOSw3 IEBAIGJhc2Vfb2JqID0KIAljbWRzLm8gY2FzZXRhYi5vIGNhc2VmaWRkbGUubyBpbmRlbnQubyBz ZWFyY2gubyByZWdleC1lbWFjcy5vIHVuZG8ubyBcCiAJYWxsb2MubyBwZHVtcGVyLm8gZGF0YS5v IGRvYy5vIGVkaXRmbnMubyBjYWxsaW50Lm8gXAogCWV2YWwubyBmbG9hdGZucy5vIGZucy5vIGZv bnQubyBwcmludC5vIGxyZWFkLm8gJChNT0RVTEVTX09CSikgXAotCXN5bnRheC5vICQoVU5FWEVD X09CSikgYnl0ZWNvZGUubyAkKENPTVBfT0JKKSBcCisJc3ludGF4Lm8gJChVTkVYRUNfT0JKKSBi eXRlY29kZS5vIGNvbXAubyAkKERZTkxJQl9PQkopIFwKIAlwcm9jZXNzLm8gZ251dGxzLm8gY2Fs bHByb2MubyBcCiAJcmVnaW9uLWNhY2hlLm8gc291bmQubyB0aW1lZm5zLm8gYXRpbWVyLm8gXAog CWRvcHJudC5vIGludGVydmFscy5vIHRleHRwcm9wLm8gY29tcG9zaXRlLm8geG1sLm8gbGNtcy5v ICQoTk9USUZZX09CSikgXApkaWZmIC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9jb21wLmMKaW5k ZXggNjk1MjVhY2ZjMC4uYjQzZDNlZGRiMyAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9z cmMvY29tcC5jCkBAIC0yMCw2ICsyMCw4IEBACiAKICNpbmNsdWRlIDxjb25maWcuaD4KIAorI2lu Y2x1ZGUgImxpc3AuaCIKKwogI2lmZGVmIEhBVkVfTkFUSVZFX0NPTVAKIAogI2luY2x1ZGUgPHNl dGptcC5oPgpAQCAtMjgsNyArMzAsNiBAQAogI2luY2x1ZGUgPHNpZ25hbC5oPgogI2luY2x1ZGUg PGxpYmdjY2ppdC5oPgogCi0jaW5jbHVkZSAibGlzcC5oIgogI2luY2x1ZGUgInB1cmVzaXplLmgi CiAjaW5jbHVkZSAid2luZG93LmgiCiAjaW5jbHVkZSAiZHlubGliLmgiCkBAIC0zNiw2ICszNywz NDcgQEAKICNpbmNsdWRlICJibG9ja2lucHV0LmgiCiAjaW5jbHVkZSAic2hhNTEyLmgiCiAKKwwK Ky8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKy8qIER5bmFtaWMgbG9hZGluZyBv ZiBsaWJnY2NqaXQgKi8KKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworI2lm ZGVmIFdJTkRPV1NOVAorIyBpbmNsdWRlICJ3MzJjb21tb24uaCIKKworI3VuZGVmIGdjY19qaXRf YmxvY2tfYWRkX2Fzc2lnbm1lbnQKKyN1bmRlZiBnY2Nfaml0X2Jsb2NrX2FkZF9jb21tZW50Cisj dW5kZWYgZ2NjX2ppdF9ibG9ja19hZGRfZXZhbAorI3VuZGVmIGdjY19qaXRfYmxvY2tfZW5kX3dp dGhfY29uZGl0aW9uYWwKKyN1bmRlZiBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2p1bXAKKyN1bmRl ZiBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX3JldHVybgorI3VuZGVmIGdjY19qaXRfYmxvY2tfZW5k X3dpdGhfdm9pZF9yZXR1cm4KKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZQorI3VuZGVm IGdjY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRf ZHVtcF9yZXByb2R1Y2VyX3RvX2ZpbGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfZHVtcF90b19m aWxlCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X2dldF9idWlsdGluX2Z1bmN0aW9uCisjdW5kZWYg Z2NjX2ppdF9jb250ZXh0X2dldF9maXJzdF9lcnJvcgorI3VuZGVmIGdjY19qaXRfY29udGV4dF9n ZXRfaW50X3R5cGUKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUKKyN1bmRlZiBnY2Nf aml0X2NvbnRleHRfbmV3X2FycmF5X2FjY2VzcworI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdf YXJyYXlfdHlwZQorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdfYmluYXJ5X29wCisjdW5kZWYg Z2NjX2ppdF9jb250ZXh0X25ld19jYWxsCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19jYWxs X3Rocm91Z2hfcHRyCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19jb21wYXJpc29uCisjdW5k ZWYgZ2NjX2ppdF9jb250ZXh0X25ld19maWVsZAorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdf ZnVuY3Rpb24KKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uX3B0cl90eXBlCisj dW5kZWYgZ2NjX2ppdF9jb250ZXh0X25ld19nbG9iYWwKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRf bmV3X29wYXF1ZV9zdHJ1Y3QKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3BhcmFtCisjdW5k ZWYgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9pbnQKKyN1bmRlZiBnY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcKKyN1bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3J2 YWx1ZV9mcm9tX3B0cgorI3VuZGVmIGdjY19qaXRfY29udGV4dF9uZXdfc3RydWN0X3R5cGUKKyN1 bmRlZiBnY2Nfaml0X2NvbnRleHRfbmV3X3VuYXJ5X29wCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0 X25ld191bmlvbl90eXBlCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3JlbGVhc2UKKyN1bmRlZiBn Y2Nfaml0X2NvbnRleHRfc2V0X2Jvb2xfb3B0aW9uCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3Nl dF9pbnRfb3B0aW9uCisjdW5kZWYgZ2NjX2ppdF9jb250ZXh0X3NldF9sb2dmaWxlCisjdW5kZWYg Z2NjX2ppdF9mdW5jdGlvbl9nZXRfcGFyYW0KKyN1bmRlZiBnY2Nfaml0X2Z1bmN0aW9uX25ld19i bG9jaworI3VuZGVmIGdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsCisjdW5kZWYgZ2NjX2ppdF9s dmFsdWVfYWNjZXNzX2ZpZWxkCisjdW5kZWYgZ2NjX2ppdF9sdmFsdWVfYXNfcnZhbHVlCisjdW5k ZWYgZ2NjX2ppdF9sdmFsdWVfZ2V0X2FkZHJlc3MKKyN1bmRlZiBnY2Nfaml0X3BhcmFtX2FzX2x2 YWx1ZQorI3VuZGVmIGdjY19qaXRfcGFyYW1fYXNfcnZhbHVlCisjdW5kZWYgZ2NjX2ppdF9ydmFs dWVfYWNjZXNzX2ZpZWxkCisjdW5kZWYgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2UKKyN1bmRl ZiBnY2Nfaml0X3J2YWx1ZV9kZXJlZmVyZW5jZV9maWVsZAorI3VuZGVmIGdjY19qaXRfcnZhbHVl X2dldF90eXBlCisjdW5kZWYgZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZQorI3VuZGVmIGdjY19qaXRf c3RydWN0X3NldF9maWVsZHMKKyN1bmRlZiBnY2Nfaml0X3R5cGVfZ2V0X3BvaW50ZXIKKworLyog SW4gYWxwaGFiZXRpY2FsIG9yZGVyICovCitERUZfRExMX0ZOIChnY2Nfaml0X3J2YWx1ZSAqLCBn Y2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCwKKyAgICAgICAgICAgIChnY2Nfaml0 X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfdHlwZSAqbnVtZXJpY190eXBlLCBpbnQgdmFsdWUpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfbHZhbHVlX2FzX3J2YWx1ZSwK KyAgICAgICAgICAgIChnY2Nfaml0X2x2YWx1ZSAqbHZhbHVlKSk7CitERUZfRExMX0ZOIChnY2Nf aml0X3J2YWx1ZSAqLCBnY2Nfaml0X3J2YWx1ZV9hY2Nlc3NfZmllbGQsCisgICAgICAgICAgICAo Z2NjX2ppdF9ydmFsdWUgKnN0cnVjdF9vcl91bmlvbiwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAor ICAgICAgICAgICAgIGdjY19qaXRfZmllbGQgKmZpZWxkKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2FkZF9jb21tZW50LAorICAgICAgICAgICAgKGdjY19qaXRfYmxvY2sgKmJs b2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsIGNvbnN0IGNoYXIgKnRleHQpKTsKK0RFRl9ETExf Rk4gKHZvaWQsIGdjY19qaXRfY29udGV4dF9yZWxlYXNlLCAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0 KSk7CitERUZfRExMX0ZOIChjb25zdCBjaGFyICosIGdjY19qaXRfY29udGV4dF9nZXRfZmlyc3Rf ZXJyb3IsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0KSk7CitERUZfRExMX0ZO IChnY2Nfaml0X2Jsb2NrICosIGdjY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrLAorICAgICAgICAg ICAgKGdjY19qaXRfZnVuY3Rpb24gKmZ1bmMsIGNvbnN0IGNoYXIgKm5hbWUpKTsKK0RFRl9ETExf Rk4gKGdjY19qaXRfY29udGV4dCAqLCBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZSwgKHZvaWQpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfZmllbGQgKiwgZ2NjX2ppdF9jb250ZXh0X25ld19maWVsZCwK KyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxv YywgZ2NjX2ppdF90eXBlICp0eXBlLAorICAgICAgICAgICAgIGNvbnN0IGNoYXIgKm5hbWUpKTsK K0RFRl9ETExfRk4gKGdjY19qaXRfZnVuY3Rpb24gKiwgZ2NjX2ppdF9jb250ZXh0X2dldF9idWls dGluX2Z1bmN0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgY29uc3Qg Y2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9mdW5jdGlvbiAqLCBnY2Nfaml0X2Nv bnRleHRfbmV3X2Z1bmN0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwg Z2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGVudW0gZ2NjX2ppdF9mdW5jdGlv bl9raW5kIGtpbmQsIGdjY19qaXRfdHlwZSAqcmV0dXJuX3R5cGUsCisgICAgICAgICAgICAgY29u c3QgY2hhciAqbmFtZSwgaW50IG51bV9wYXJhbXMsIGdjY19qaXRfcGFyYW0gKipwYXJhbXMsCisg ICAgICAgICAgICAgaW50IGlzX3ZhcmlhZGljKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X2x2YWx1 ZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X2FjY2VzcywKKyAgICAgICAgICAgIChnY2Nf aml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxvYywgZ2NjX2ppdF9ydmFsdWUg KnB0ciwKKyAgICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqaW5kZXgpKTsKK0RFRl9ETExfRk4g KGdjY19qaXRfbHZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfZ2xvYmFsLAorICAgICAgICAg ICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAg ICAgICAgIGVudW0gZ2NjX2ppdF9nbG9iYWxfa2luZCBraW5kLCBnY2Nfaml0X3R5cGUgKnR5cGUs CisgICAgICAgICAgICAgY29uc3QgY2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9s dmFsdWUgKiwgZ2NjX2ppdF9mdW5jdGlvbl9uZXdfbG9jYWwsCisgICAgICAgICAgICAoZ2NjX2pp dF9mdW5jdGlvbiAqZnVuYywgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLCBnY2Nfaml0X3R5cGUgKnR5 cGUsCisgICAgICAgICAgICAgY29uc3QgY2hhciAqbmFtZSkpOworREVGX0RMTF9GTiAoZ2NjX2pp dF9sdmFsdWUgKiwgZ2NjX2ppdF9sdmFsdWVfYWNjZXNzX2ZpZWxkLAorICAgICAgICAgICAgKGdj Y19qaXRfbHZhbHVlICpzdHJ1Y3Rfb3JfdW5pb24sIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X2ZpZWxkICpmaWVsZCkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9s dmFsdWUgKiwgZ2NjX2ppdF9wYXJhbV9hc19sdmFsdWUsIChnY2Nfaml0X3BhcmFtICpwYXJhbSkp OworREVGX0RMTF9GTiAoZ2NjX2ppdF9sdmFsdWUgKiwgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVu Y2UsCisgICAgICAgICAgICAoZ2NjX2ppdF9ydmFsdWUgKnJ2YWx1ZSwgZ2NjX2ppdF9sb2NhdGlv biAqbG9jKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X2x2YWx1ZSAqLCBnY2Nfaml0X3J2YWx1ZV9k ZXJlZmVyZW5jZV9maWVsZCwKKyAgICAgICAgICAgIChnY2Nfaml0X3J2YWx1ZSAqcHRyLCBnY2Nf aml0X2xvY2F0aW9uICpsb2MsIGdjY19qaXRfZmllbGQgKmZpZWxkKSk7CitERUZfRExMX0ZOIChn Y2Nfaml0X3BhcmFtICosIGdjY19qaXRfY29udGV4dF9uZXdfcGFyYW0sCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsIGdjY19qaXRfdHlw ZSAqdHlwZSwKKyAgICAgICAgICAgICBjb25zdCBjaGFyICpuYW1lKSk7CitERUZfRExMX0ZOIChn Y2Nfaml0X3BhcmFtICosIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtLAorICAgICAgICAgICAg KGdjY19qaXRfZnVuY3Rpb24gKmZ1bmMsIGludCBpbmRleCkpOworREVGX0RMTF9GTiAoZ2NjX2pp dF9ydmFsdWUgKiwgZ2NjX2ppdF9jb250ZXh0X25ld19iaW5hcnlfb3AsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAg ICAgZW51bSBnY2Nfaml0X2JpbmFyeV9vcCBvcCwgZ2NjX2ppdF90eXBlICpyZXN1bHRfdHlwZSwK KyAgICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqYSwgZ2NjX2ppdF9ydmFsdWUgKmIpKTsKK0RF Rl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbCwKKyAg ICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24gKmxvYywK KyAgICAgICAgICAgICBnY2Nfaml0X2Z1bmN0aW9uICpmdW5jLCBpbnQgbnVtYXJncyAsIGdjY19q aXRfcnZhbHVlICoqYXJncykpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2pp dF9jb250ZXh0X25ld19jYWxsX3Rocm91Z2hfcHRyLAorICAgICAgICAgICAgKGdjY19qaXRfY29u dGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRf cnZhbHVlICpmbl9wdHIsIGludCBudW1hcmdzLCBnY2Nfaml0X3J2YWx1ZSAqKmFyZ3MpKTsKK0RF Rl9ETExfRk4gKGdjY19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfY29tcGFyaXNv biwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGdjY19qaXRfbG9jYXRpb24g KmxvYywKKyAgICAgICAgICAgICBlbnVtIGdjY19qaXRfY29tcGFyaXNvbiBvcCwgZ2NjX2ppdF9y dmFsdWUgKmEsIGdjY19qaXRfcnZhbHVlICpiKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X3J2YWx1 ZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2xvbmcsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X3R5cGUgKm51bWVyaWNfdHlwZSwgbG9uZyB2 YWx1ZSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2ppdF9jb250ZXh0X25l d19ydmFsdWVfZnJvbV9wdHIsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBn Y2Nfaml0X3R5cGUgKnBvaW50ZXJfdHlwZSwgdm9pZCAqdmFsdWUpKTsKK0RFRl9ETExfRk4gKGdj Y19qaXRfcnZhbHVlICosIGdjY19qaXRfY29udGV4dF9uZXdfdW5hcnlfb3AsCisgICAgICAgICAg ICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAg ICAgICAgZW51bSBnY2Nfaml0X3VuYXJ5X29wIG9wLCBnY2Nfaml0X3R5cGUgKnJlc3VsdF90eXBl LAorICAgICAgICAgICAgIGdjY19qaXRfcnZhbHVlICpydmFsdWUpKTsKK0RFRl9ETExfRk4gKGdj Y19qaXRfcnZhbHVlICosIGdjY19qaXRfbHZhbHVlX2dldF9hZGRyZXNzLAorICAgICAgICAgICAg KGdjY19qaXRfbHZhbHVlICpsdmFsdWUsIGdjY19qaXRfbG9jYXRpb24gKmxvYykpOworREVGX0RM TF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2ppdF9wYXJhbV9hc19ydmFsdWUsIChnY2Nfaml0 X3BhcmFtICpwYXJhbSkpOworREVGX0RMTF9GTiAoZ2NjX2ppdF9zdHJ1Y3QgKiwgZ2NjX2ppdF9j b250ZXh0X25ld19vcGFxdWVfc3RydWN0LAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAq Y3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9jLCBjb25zdCBjaGFyICpuYW1lKSk7CitERUZfRExM X0ZOIChnY2Nfaml0X3N0cnVjdCAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X3N0cnVjdF90eXBlLAor ICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlvbiAqbG9j LCBjb25zdCBjaGFyICpuYW1lLAorICAgICAgICAgICAgIGludCBudW1fZmllbGRzLCBnY2Nfaml0 X2ZpZWxkICoqZmllbGRzKSk7CitERUZfRExMX0ZOIChnY2Nfaml0X3R5cGUgKiwgZ2NjX2ppdF9j b250ZXh0X2dldF9pbnRfdHlwZSwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQs IGludCBudW1fYnl0ZXMsIGludCBpc19zaWduZWQpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlw ZSAqLCBnY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250 ZXh0ICpjdHh0LCBlbnVtIGdjY19qaXRfdHlwZXMgdHlwZV8pKTsKK0RFRl9ETExfRk4gKGdjY19q aXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X3R5cGUsCisgICAgICAgICAgICAo Z2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAg ICAgZ2NjX2ppdF90eXBlICplbGVtZW50X3R5cGUsIGludCBudW1fZWxlbWVudHMpKTsKK0RFRl9E TExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uX3B0cl90 eXBlLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZ2NjX2ppdF9sb2NhdGlv biAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRfdHlwZSAqcmV0dXJuX3R5cGUsIGludCBudW1f cGFyYW1zLAorICAgICAgICAgICAgIGdjY19qaXRfdHlwZSAqKnBhcmFtX3R5cGVzLCBpbnQgaXNf dmFyaWFkaWMpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X2NvbnRleHRf bmV3X3VuaW9uX3R5cGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250ZXh0ICpjdHh0LCBnY2Nf aml0X2xvY2F0aW9uICpsb2MsIGNvbnN0IGNoYXIgKm5hbWUsCisgICAgICAgICAgICAgaW50IG51 bV9maWVsZHMsIGdjY19qaXRfZmllbGQgKipmaWVsZHMpKTsKK0RFRl9ETExfRk4gKGdjY19qaXRf dHlwZSAqLCBnY2Nfaml0X3J2YWx1ZV9nZXRfdHlwZSwgKGdjY19qaXRfcnZhbHVlICpydmFsdWUp KTsKK0RFRl9ETExfRk4gKGdjY19qaXRfdHlwZSAqLCBnY2Nfaml0X3N0cnVjdF9hc190eXBlLAor ICAgICAgICAgICAgKGdjY19qaXRfc3RydWN0ICpzdHJ1Y3RfdHlwZSkpOworREVGX0RMTF9GTiAo Z2NjX2ppdF90eXBlICosIGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciwgKGdjY19qaXRfdHlwZSAq dHlwZSkpOworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9ibG9ja19hZGRfYXNzaWdubWVudCwK KyAgICAgICAgICAgIChnY2Nfaml0X2Jsb2NrICpibG9jaywgZ2NjX2ppdF9sb2NhdGlvbiAqbG9j LCBnY2Nfaml0X2x2YWx1ZSAqbHZhbHVlLAorICAgICAgICAgICAgIGdjY19qaXRfcnZhbHVlICpy dmFsdWUpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRfYmxvY2tfYWRkX2V2YWwsCisgICAg ICAgICAgICAoZ2NjX2ppdF9ibG9jayAqYmxvY2ssIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqcnZhbHVlKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2VuZF93aXRoX2NvbmRpdGlvbmFsLAorICAgICAgICAgICAgKGdjY19qaXRf YmxvY2sgKmJsb2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MsCisgICAgICAgICAgICAgZ2NjX2pp dF9ydmFsdWUgKmJvb2x2YWwsIGdjY19qaXRfYmxvY2sgKm9uX3RydWUsCisgICAgICAgICAgICAg Z2NjX2ppdF9ibG9jayAqb25fZmFsc2UpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRfYmxv Y2tfZW5kX3dpdGhfanVtcCwKKyAgICAgICAgICAgIChnY2Nfaml0X2Jsb2NrICpibG9jaywgZ2Nj X2ppdF9sb2NhdGlvbiAqbG9jLAorICAgICAgICAgICAgIGdjY19qaXRfYmxvY2sgKnRhcmdldCkp OworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9yZXR1cm4sCisgICAg ICAgICAgICAoZ2NjX2ppdF9ibG9jayAqYmxvY2ssIGdjY19qaXRfbG9jYXRpb24gKmxvYywKKyAg ICAgICAgICAgICBnY2Nfaml0X3J2YWx1ZSAqcnZhbHVlKSk7CitERUZfRExMX0ZOICh2b2lkLCBn Y2Nfaml0X2Jsb2NrX2VuZF93aXRoX3ZvaWRfcmV0dXJuLAorICAgICAgICAgICAgKGdjY19qaXRf YmxvY2sgKmJsb2NrLCBnY2Nfaml0X2xvY2F0aW9uICpsb2MpKTsKK0RFRl9ETExfRk4gKHZvaWQs IGdjY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9j b250ZXh0ICpjdHh0LCBlbnVtIGdjY19qaXRfb3V0cHV0X2tpbmQgb3V0cHV0X2tpbmQsCisgICAg ICAgICAgICAgY29uc3QgY2hhciAqb3V0cHV0X3BhdGgpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdj Y19qaXRfY29udGV4dF9kdW1wX3JlcHJvZHVjZXJfdG9fZmlsZSwKKyAgICAgICAgICAgIChnY2Nf aml0X2NvbnRleHQgKmN0eHQsIGNvbnN0IGNoYXIgKnBhdGgpKTsKK0RFRl9ETExfRk4gKHZvaWQs IGdjY19qaXRfY29udGV4dF9kdW1wX3RvX2ZpbGUsCisgICAgICAgICAgICAoZ2NjX2ppdF9jb250 ZXh0ICpjdHh0LCBjb25zdCBjaGFyICpwYXRoLCBpbnQgdXBkYXRlX2xvY2F0aW9ucykpOworREVG X0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9jb250ZXh0X3NldF9ib29sX29wdGlvbiwKKyAgICAgICAg ICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQsIGVudW0gZ2NjX2ppdF9ib29sX29wdGlvbiBvcHQs IGludCB2YWx1ZSkpOworREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9jb250ZXh0X3NldF9pbnRf b3B0aW9uLAorICAgICAgICAgICAgKGdjY19qaXRfY29udGV4dCAqY3R4dCwgZW51bSBnY2Nfaml0 X2ludF9vcHRpb24gb3B0LCBpbnQgdmFsdWUpKTsKK0RFRl9ETExfRk4gKHZvaWQsIGdjY19qaXRf Y29udGV4dF9zZXRfbG9nZmlsZSwKKyAgICAgICAgICAgIChnY2Nfaml0X2NvbnRleHQgKmN0eHQs IEZJTEUgKmxvZ2ZpbGUsIGludCBmbGFncywgaW50IHZlcmJvc2l0eSkpOworREVGX0RMTF9GTiAo dm9pZCwgZ2NjX2ppdF9zdHJ1Y3Rfc2V0X2ZpZWxkcywKKyAgICAgICAgICAgIChnY2Nfaml0X3N0 cnVjdCAqc3RydWN0X3R5cGUsIGdjY19qaXRfbG9jYXRpb24gKmxvYywgaW50IG51bV9maWVsZHMs CisgICAgICAgICAgICAgZ2NjX2ppdF9maWVsZCAqKmZpZWxkcykpOworCitzdGF0aWMgYm9vbAor aW5pdF9nY2NqaXRfZnVuY3Rpb25zICh2b2lkKQoreworICBITU9EVUxFIGxpYnJhcnk7CisKKyAg aWYgKCEobGlicmFyeSA9IHczMl9kZWxheWVkX2xvYWQgKFFnY2NqaXQpKSkKKyAgICB7CisgICAg ICByZXR1cm4gZmFsc2U7CisgICAgfQorCisgIC8qIEluIGFscGhhYmV0aWNhbCBvcmRlciAqLwor ICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2FkZF9hc3NpZ25tZW50KTsKKyAg TE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9ibG9ja19hZGRfY29tbWVudCk7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfYmxvY2tfYWRkX2V2YWwpOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2NvbmRpdGlvbmFsKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9qdW1wKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF9yZXR1cm4pOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX3ZvaWRfcmV0dXJuKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2FjcXVpcmUpOworICBMT0FEX0RMTF9GTihsaWJy YXJ5LCBnY2Nfaml0X2NvbnRleHRfY29tcGlsZV90b19maWxlKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF9jb250ZXh0X2R1bXBfcmVwcm9kdWNlcl90b19maWxlKTsKKyAgTE9BRF9E TExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2R1bXBfdG9fZmlsZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9nZXRfYnVpbHRpbl9mdW5jdGlvbik7CisgIExP QURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9nZXRfZmlyc3RfZXJyb3IpOworICBM T0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfZ2V0X2ludF90eXBlKTsKKyAgTE9B RF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X2dldF90eXBlKTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV9hY2Nlc3MpOworICBMT0FEX0RM TF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X3R5cGUpOworICBMT0FEX0RM TF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcCk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbCk7CisgIExPQURfRExMX0ZOKGxp YnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY2FsbF90aHJvdWdoX3B0cik7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfY29tcGFyaXNvbik7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfZmllbGQpOworICBMT0FEX0RMTF9GTihs aWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19mdW5jdGlvbl9wdHJfdHlwZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfZ2xvYmFsKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19vcGFxdWVfc3RydWN0KTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19wYXJhbSk7CisgIExPQURfRExMX0ZOKGxp YnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21faW50KTsKKyAgTE9BRF9ETExf Rk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9sb25nKTsKKyAgTE9B RF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9wdHIpOwor ICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X2NvbnRleHRfbmV3X3N0cnVjdF90eXBlKTsK KyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X25ld191bmFyeV9vcCk7Cisg IExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9uZXdfdW5pb25fdHlwZSk7Cisg IExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9yZWxlYXNlKTsKKyAgTE9BRF9E TExfRk4obGlicmFyeSwgZ2NjX2ppdF9jb250ZXh0X3NldF9ib29sX29wdGlvbik7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9zZXRfaW50X29wdGlvbik7CisgIExPQURf RExMX0ZOKGxpYnJhcnksIGdjY19qaXRfY29udGV4dF9zZXRfbG9nZmlsZSk7CisgIExPQURfRExM X0ZOKGxpYnJhcnksIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtKTsKKyAgTE9BRF9ETExfRk4o bGlicmFyeSwgZ2NjX2ppdF9mdW5jdGlvbl9uZXdfYmxvY2spOworICBMT0FEX0RMTF9GTihsaWJy YXJ5LCBnY2Nfaml0X2Z1bmN0aW9uX25ld19sb2NhbCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnks IGdjY19qaXRfbHZhbHVlX2FjY2Vzc19maWVsZCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdj Y19qaXRfbHZhbHVlX2FzX3J2YWx1ZSk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRf bHZhbHVlX2dldF9hZGRyZXNzKTsKKyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9wYXJh bV9hc19sdmFsdWUpOworICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X3BhcmFtX2FzX3J2 YWx1ZSk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfcnZhbHVlX2FjY2Vzc19maWVs ZCk7CisgIExPQURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlKTsK KyAgTE9BRF9ETExfRk4obGlicmFyeSwgZ2NjX2ppdF9ydmFsdWVfZGVyZWZlcmVuY2VfZmllbGQp OworICBMT0FEX0RMTF9GTihsaWJyYXJ5LCBnY2Nfaml0X3J2YWx1ZV9nZXRfdHlwZSk7CisgIExP QURfRExMX0ZOKGxpYnJhcnksIGdjY19qaXRfc3RydWN0X2FzX3R5cGUpOworICBMT0FEX0RMTF9G TihsaWJyYXJ5LCBnY2Nfaml0X3N0cnVjdF9zZXRfZmllbGRzKTsKKyAgTE9BRF9ETExfRk4obGli cmFyeSwgZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyKTsKKworICByZXR1cm4gdHJ1ZTsKK30KKwor LyogSW4gYWxwaGFiZXRpY2FsIG9yZGVyICovCisjZGVmaW5lIGdjY19qaXRfYmxvY2tfYWRkX2Fz c2lnbm1lbnQgZm5fZ2NjX2ppdF9ibG9ja19hZGRfYXNzaWdubWVudAorI2RlZmluZSBnY2Nfaml0 X2Jsb2NrX2FkZF9jb21tZW50IGZuX2djY19qaXRfYmxvY2tfYWRkX2NvbW1lbnQKKyNkZWZpbmUg Z2NjX2ppdF9ibG9ja19hZGRfZXZhbCBmbl9nY2Nfaml0X2Jsb2NrX2FkZF9ldmFsCisjZGVmaW5l IGdjY19qaXRfYmxvY2tfZW5kX3dpdGhfY29uZGl0aW9uYWwgZm5fZ2NjX2ppdF9ibG9ja19lbmRf d2l0aF9jb25kaXRpb25hbAorI2RlZmluZSBnY2Nfaml0X2Jsb2NrX2VuZF93aXRoX2p1bXAgZm5f Z2NjX2ppdF9ibG9ja19lbmRfd2l0aF9qdW1wCisjZGVmaW5lIGdjY19qaXRfYmxvY2tfZW5kX3dp dGhfcmV0dXJuIGZuX2djY19qaXRfYmxvY2tfZW5kX3dpdGhfcmV0dXJuCisjZGVmaW5lIGdjY19q aXRfYmxvY2tfZW5kX3dpdGhfdm9pZF9yZXR1cm4gZm5fZ2NjX2ppdF9ibG9ja19lbmRfd2l0aF92 b2lkX3JldHVybgorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfYWNxdWlyZSBmbl9nY2Nfaml0X2Nv bnRleHRfYWNxdWlyZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfY29tcGlsZV90b19maWxlIGZu X2djY19qaXRfY29udGV4dF9jb21waWxlX3RvX2ZpbGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0 X2R1bXBfcmVwcm9kdWNlcl90b19maWxlIGZuX2djY19qaXRfY29udGV4dF9kdW1wX3JlcHJvZHVj ZXJfdG9fZmlsZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfZHVtcF90b19maWxlIGZuX2djY19q aXRfY29udGV4dF9kdW1wX3RvX2ZpbGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X2dldF9idWls dGluX2Z1bmN0aW9uIGZuX2djY19qaXRfY29udGV4dF9nZXRfYnVpbHRpbl9mdW5jdGlvbgorI2Rl ZmluZSBnY2Nfaml0X2NvbnRleHRfZ2V0X2ZpcnN0X2Vycm9yIGZuX2djY19qaXRfY29udGV4dF9n ZXRfZmlyc3RfZXJyb3IKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X2dldF9pbnRfdHlwZSBmbl9n Y2Nfaml0X2NvbnRleHRfZ2V0X2ludF90eXBlCisjZGVmaW5lIGdjY19qaXRfY29udGV4dF9nZXRf dHlwZSBmbl9nY2Nfaml0X2NvbnRleHRfZ2V0X3R5cGUKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0 X25ld19hcnJheV9hY2Nlc3MgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV9hY2Nlc3MKKyNk ZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV90eXBlIGZuX2djY19qaXRfY29udGV4dF9u ZXdfYXJyYXlfdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcCBmbl9n Y2Nfaml0X2NvbnRleHRfbmV3X2JpbmFyeV9vcAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3 X2NhbGwgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19jYWxsCisjZGVmaW5lIGdjY19qaXRfY29udGV4 dF9uZXdfY2FsbF90aHJvdWdoX3B0ciBmbl9nY2Nfaml0X2NvbnRleHRfbmV3X2NhbGxfdGhyb3Vn aF9wdHIKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld19jb21wYXJpc29uIGZuX2djY19qaXRf Y29udGV4dF9uZXdfY29tcGFyaXNvbgorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2ZpZWxk IGZuX2djY19qaXRfY29udGV4dF9uZXdfZmllbGQKKyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25l d19mdW5jdGlvbiBmbl9nY2Nfaml0X2NvbnRleHRfbmV3X2Z1bmN0aW9uCisjZGVmaW5lIGdjY19q aXRfY29udGV4dF9uZXdfZnVuY3Rpb25fcHRyX3R5cGUgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19m dW5jdGlvbl9wdHJfdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X2dsb2JhbCBmbl9n Y2Nfaml0X2NvbnRleHRfbmV3X2dsb2JhbAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X29w YXF1ZV9zdHJ1Y3QgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19vcGFxdWVfc3RydWN0CisjZGVmaW5l IGdjY19qaXRfY29udGV4dF9uZXdfcGFyYW0gZm5fZ2NjX2ppdF9jb250ZXh0X25ld19wYXJhbQor I2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludCBmbl9nY2Nfaml0X2Nv bnRleHRfbmV3X3J2YWx1ZV9mcm9tX2ludAorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfbmV3X3J2 YWx1ZV9mcm9tX2xvbmcgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9sb25nCisj ZGVmaW5lIGdjY19qaXRfY29udGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyIGZuX2djY19qaXRfY29u dGV4dF9uZXdfcnZhbHVlX2Zyb21fcHRyCisjZGVmaW5lIGdjY19qaXRfY29udGV4dF9uZXdfc3Ry dWN0X3R5cGUgZm5fZ2NjX2ppdF9jb250ZXh0X25ld19zdHJ1Y3RfdHlwZQorI2RlZmluZSBnY2Nf aml0X2NvbnRleHRfbmV3X3VuYXJ5X29wIGZuX2djY19qaXRfY29udGV4dF9uZXdfdW5hcnlfb3AK KyNkZWZpbmUgZ2NjX2ppdF9jb250ZXh0X25ld191bmlvbl90eXBlIGZuX2djY19qaXRfY29udGV4 dF9uZXdfdW5pb25fdHlwZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfcmVsZWFzZSBmbl9nY2Nf aml0X2NvbnRleHRfcmVsZWFzZQorI2RlZmluZSBnY2Nfaml0X2NvbnRleHRfc2V0X2Jvb2xfb3B0 aW9uIGZuX2djY19qaXRfY29udGV4dF9zZXRfYm9vbF9vcHRpb24KKyNkZWZpbmUgZ2NjX2ppdF9j b250ZXh0X3NldF9pbnRfb3B0aW9uIGZuX2djY19qaXRfY29udGV4dF9zZXRfaW50X29wdGlvbgor I2RlZmluZSBnY2Nfaml0X2NvbnRleHRfc2V0X2xvZ2ZpbGUgZm5fZ2NjX2ppdF9jb250ZXh0X3Nl dF9sb2dmaWxlCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fZ2V0X3BhcmFtIGZuX2djY19qaXRf ZnVuY3Rpb25fZ2V0X3BhcmFtCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrIGZu X2djY19qaXRfZnVuY3Rpb25fbmV3X2Jsb2NrCisjZGVmaW5lIGdjY19qaXRfZnVuY3Rpb25fbmV3 X2xvY2FsIGZuX2djY19qaXRfZnVuY3Rpb25fbmV3X2xvY2FsCisjZGVmaW5lIGdjY19qaXRfbHZh bHVlX2FjY2Vzc19maWVsZCBmbl9nY2Nfaml0X2x2YWx1ZV9hY2Nlc3NfZmllbGQKKyNkZWZpbmUg Z2NjX2ppdF9sdmFsdWVfYXNfcnZhbHVlIGZuX2djY19qaXRfbHZhbHVlX2FzX3J2YWx1ZQorI2Rl ZmluZSBnY2Nfaml0X2x2YWx1ZV9nZXRfYWRkcmVzcyBmbl9nY2Nfaml0X2x2YWx1ZV9nZXRfYWRk cmVzcworI2RlZmluZSBnY2Nfaml0X3BhcmFtX2FzX2x2YWx1ZSBmbl9nY2Nfaml0X3BhcmFtX2Fz X2x2YWx1ZQorI2RlZmluZSBnY2Nfaml0X3BhcmFtX2FzX3J2YWx1ZSBmbl9nY2Nfaml0X3BhcmFt X2FzX3J2YWx1ZQorI2RlZmluZSBnY2Nfaml0X3J2YWx1ZV9hY2Nlc3NfZmllbGQgZm5fZ2NjX2pp dF9ydmFsdWVfYWNjZXNzX2ZpZWxkCisjZGVmaW5lIGdjY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNl IGZuX2djY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlCisjZGVmaW5lIGdjY19qaXRfcnZhbHVlX2Rl cmVmZXJlbmNlX2ZpZWxkIGZuX2djY19qaXRfcnZhbHVlX2RlcmVmZXJlbmNlX2ZpZWxkCisjZGVm aW5lIGdjY19qaXRfcnZhbHVlX2dldF90eXBlIGZuX2djY19qaXRfcnZhbHVlX2dldF90eXBlCisj ZGVmaW5lIGdjY19qaXRfc3RydWN0X2FzX3R5cGUgZm5fZ2NjX2ppdF9zdHJ1Y3RfYXNfdHlwZQor I2RlZmluZSBnY2Nfaml0X3N0cnVjdF9zZXRfZmllbGRzIGZuX2djY19qaXRfc3RydWN0X3NldF9m aWVsZHMKKyNkZWZpbmUgZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyIGZuX2djY19qaXRfdHlwZV9n ZXRfcG9pbnRlcgorCisjZW5kaWYKKworc3RhdGljIGJvb2wKK2xvYWRfZ2Njaml0X2lmX25lY2Vz c2FyeSAoYm9vbCBtYW5kYXRvcnkpCit7CisjaWZkZWYgV0lORE9XU05UCisgIHN0YXRpYyBib29s IHRyaWVkX3RvX2luaXRpYWxpemVfb25jZTsKKyAgc3RhdGljIGJvb2wgZ2Njaml0X2luaXRpYWxp emVkOworCisgIGlmICghdHJpZWRfdG9faW5pdGlhbGl6ZV9vbmNlKQorICAgIHsKKyAgICAgIHRy aWVkX3RvX2luaXRpYWxpemVfb25jZSA9IHRydWU7CisgICAgICBMaXNwX09iamVjdCBzdGF0dXM7 CisgICAgICBnY2NqaXRfaW5pdGlhbGl6ZWQgPSBpbml0X2djY2ppdF9mdW5jdGlvbnMgKCk7Cisg ICAgICBzdGF0dXMgPSBnY2NqaXRfaW5pdGlhbGl6ZWQgPyBRdCA6IFFuaWw7CisgICAgICBWbGli cmFyeV9jYWNoZSA9IEZjb25zIChGY29ucyAoUWdjY2ppdCwgc3RhdHVzKSwgVmxpYnJhcnlfY2Fj aGUpOworICAgIH0KKworICBpZiAobWFuZGF0b3J5ICYmICFnY2NqaXRfaW5pdGlhbGl6ZWQpCisg ICAgeHNpZ25hbDEoUW5hdGl2ZV9jb21waWxlcl9lcnJvciwgYnVpbGRfc3RyaW5nKCJsaWJnY2Nq aXQgbm90IGZvdW5kIikpOworCisgIHJldHVybiBnY2NqaXRfaW5pdGlhbGl6ZWQ7CisjZWxzZQor ICByZXR1cm4gdHJ1ZTsKKyNlbmRpZgorfQorCisMCiAvKiBDIHN5bWJvbHMgZW1pdHRlZCBmb3Ig dGhlIGxvYWQgcmVsb2NhdGlvbiBtZWNoYW5pc20uICAqLwogI2RlZmluZSBDVVJSRU5UX1RIUkVB RF9SRUxPQ19TWU0gImN1cnJlbnRfdGhyZWFkX3JlbG9jIgogI2RlZmluZSBQVVJFX1BUUl9TWU0g InB1cmVfcHRyIgpAQCAtMzMyOCw2ICszNjcwLDggQEAgREVGVU4gKCJjb21wLS1pbml0LWN0eHQi LCBGY29tcF9faW5pdF9jdHh0LCBTY29tcF9faW5pdF9jdHh0LAogICAgICAgIGRvYzogLyogSW5p dGlhbGl6ZSB0aGUgbmF0aXZlIGNvbXBpbGVyIGNvbnRleHQuIFJldHVybiB0IG9uIHN1Y2Nlc3Mu ICAqLykKICAgICAgKHZvaWQpCiB7CisgIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSh0cnVlKTsK KwogICBpZiAoY29tcC5jdHh0KQogICAgIHsKICAgICAgIHhzaWduYWwxIChRbmF0aXZlX2ljZSwK QEAgLTM0NzQsNiArMzgxOCw4IEBAIERFRlVOICgiY29tcC0tcmVsZWFzZS1jdHh0IiwgRmNvbXBf X3JlbGVhc2VfY3R4dCwgU2NvbXBfX3JlbGVhc2VfY3R4dCwKICAgICAgICBkb2M6IC8qIFJlbGVh c2UgdGhlIG5hdGl2ZSBjb21waWxlciBjb250ZXh0LiAgKi8pCiAgICAgICh2b2lkKQogeworICBs b2FkX2djY2ppdF9pZl9uZWNlc3NhcnkodHJ1ZSk7CisKICAgaWYgKGNvbXAuY3R4dCkKICAgICBn Y2Nfaml0X2NvbnRleHRfcmVsZWFzZSAoY29tcC5jdHh0KTsKIApAQCAtMzQ5MCw2ICszODM2LDgg QEAgREVGVU4gKCJjb21wLS1jb21waWxlLWN0eHQtdG8tZmlsZSIsIEZjb21wX19jb21waWxlX2N0 eHRfdG9fZmlsZSwKICAgICAgICBkb2M6IC8qIENvbXBpbGUgYXMgbmF0aXZlIGNvZGUgdGhlIGN1 cnJlbnQgY29udGV4dCB0byBmaWxlLiAgKi8pCiAgICAgIChMaXNwX09iamVjdCBiYXNlX25hbWUp CiB7CisgIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSh0cnVlKTsKKwogICBDSEVDS19TVFJJTkcg KGJhc2VfbmFtZSk7CiAKICAgZ2NjX2ppdF9jb250ZXh0X3NldF9pbnRfb3B0aW9uIChjb21wLmN0 eHQsCkBAIC0zNjYwLDYgKzQwMDgsOSBAQCBtYXliZV9kZWZlcl9uYXRpdmVfY29tcGlsYXRpb24g KExpc3BfT2JqZWN0IGZ1bmN0aW9uX25hbWUsCiAgICAgICBmZmx1c2ggKGYpOwogICAgIH0KICNl bmRpZgorICBpZiAoIWxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeShmYWxzZSkpCisgICAgcmV0dXJu OworCiAgIGlmICghY29tcF9kZWZlcnJlZF9jb21waWxhdGlvbgogICAgICAgfHwgbm9uaW50ZXJh Y3RpdmUKICAgICAgIHx8ICFOSUxQIChWcHVyaWZ5X2ZsYWcpCkBAIC0zOTI4LDEwICs0Mjc5LDI2 IEBAIERFRlVOICgibmF0aXZlLWVsaXNwLWxvYWQiLCBGbmF0aXZlX2VsaXNwX2xvYWQsIFNuYXRp dmVfZWxpc3BfbG9hZCwgMSwgMiwgMCwKICAgcmV0dXJuIFF0OwogfQogCisjZW5kaWYgLyogSEFW RV9OQVRJVkVfQ09NUCAqLworCitERUZVTiAoIm5hdGl2ZS1jb21wLWF2YWlsYWJsZS1wIiwgRm5h dGl2ZV9jb21wX2F2YWlsYWJsZV9wLAorICAgICAgIFNuYXRpdmVfY29tcF9hdmFpbGFibGVfcCwg MCwgMCwgMCwKKyAgICAgICBkb2M6IC8qIFJldHVybnMgdCBpZiBuYXRpdmUgY29tcGlsYXRpb24g b2YgTGlzcCBmaWxlcyBpcyBhdmFpbGFibGUgaW4KK3RoaXMgaW5zdGFuY2Ugb2YgRW1hY3MuICov KQorICAodm9pZCkKK3sKKyNpZmRlZiBIQVZFX05BVElWRV9DT01QCisgIHJldHVybiBsb2FkX2dj Y2ppdF9pZl9uZWNlc3NhcnkoZmFsc2UpID8gUXQgOiBRbmlsOworI2Vsc2UKKyAgcmV0dXJuIFFu aWw7CisjZW5kaWYKK30KKwogDAogdm9pZAogc3ltc19vZl9jb21wICh2b2lkKQogeworI2lmZGVm IEhBVkVfTkFUSVZFX0NPTVAKICAgLyogQ29tcGlsZXIgY29udHJvbCBjdXN0b21pemVzLiAgKi8K ICAgREVGVkFSX0JPT0wgKCJjb21wLWRlZmVycmVkLWNvbXBpbGF0aW9uIiwgY29tcF9kZWZlcnJl ZF9jb21waWxhdGlvbiwKIAkgICAgICAgZG9jOiAvKiBJZiB0IGNvbXBpbGUgYXN5bmNyb25vdXNs eSBldmVyeSAuZWxjIGZpbGUgbG9hZGVkLiAgKi8pOwpAQCAtNDA3Myw2ICs0NDQwLDcgQEAgc3lt c19vZl9jb21wICh2b2lkKQogCSAgICAgICBkb2M6IC8qIEhhc2ggdGFibGUgc3ltYm9sLW5hbWUg LT4gZnVuY3Rpb24tdmFsdWUuICBGb3IKIAkJICAgICAgIGludGVybmFsIHVzZSBkdXJpbmcgICov KTsKICAgVmNvbXBfZGVmZXJyZWRfcGVuZGluZ19oID0gQ0FMTE4gKEZtYWtlX2hhc2hfdGFibGUs IFFDdGVzdCwgUWVxKTsKLX0KKyNlbmRpZgogCi0jZW5kaWYgLyogSEFWRV9OQVRJVkVfQ09NUCAq LworICBkZWZzdWJyICgmU25hdGl2ZV9jb21wX2F2YWlsYWJsZV9wKTsKK30KZGlmZiAtLWdpdCBh L3NyYy9jb21wLmggYi9zcmMvY29tcC5oCmluZGV4IGNiZGNhY2NkNWYuLmU2YWIzMmZmOGUgMTAw NjQ0Ci0tLSBhL3NyYy9jb21wLmgKKysrIGIvc3JjL2NvbXAuaApAQCAtODIsMTEgKzgyLDcgQEAg bWF5YmVfZGVmZXJfbmF0aXZlX2NvbXBpbGF0aW9uIChMaXNwX09iamVjdCBmdW5jdGlvbl9uYW1l LAogCQkJCUxpc3BfT2JqZWN0IGRlZmluaXRpb24pCiB7fQogCi1zdGF0aWMgaW5saW5lIExpc3Bf T2JqZWN0Ci1GbmF0aXZlX2VsaXNwX2xvYWQgKExpc3BfT2JqZWN0IGZpbGUsIExpc3BfT2JqZWN0 IGxhdGVfbG9hZCkKLXsKLSAgZWFzc3VtZSAoZmFsc2UpOwotfQorZXh0ZXJuIHZvaWQgc3ltc19v Zl9jb21wICh2b2lkKTsKIAogI2VuZGlmCiAKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy5jIGIvc3Jj L2VtYWNzLmMKaW5kZXggMmM5MDgyNTc0Mi4uZTc1Y2I1ODgzNCAxMDA2NDQKLS0tIGEvc3JjL2Vt YWNzLmMKKysrIGIvc3JjL2VtYWNzLmMKQEAgLTE2MDYsMTAgKzE2MDYsOCBAQCBtYWluIChpbnQg YXJnYywgY2hhciAqKmFyZ3YpCiAgIGluaXRfanNvbiAoKTsKICNlbmRpZgogCi0jaWZkZWYgSEFW RV9OQVRJVkVfQ09NUAogICBpZiAoIWluaXRpYWxpemVkKQogICAgIHN5bXNfb2ZfY29tcCAoKTsK LSNlbmRpZgogCiAgIG5vX2xvYWR1cAogICAgID0gYXJnbWF0Y2ggKGFyZ3YsIGFyZ2MsICItbmwi LCAiLS1uby1sb2FkdXAiLCA2LCBOVUxMLCAmc2tpcF9hcmdzKTsKZGlmZiAtLWdpdCBhL3NyYy93 MzIuYyBiL3NyYy93MzIuYwppbmRleCAxZWMwMDk0YzhlLi5mZDFmMGUwNTllIDEwMDY0NAotLS0g YS9zcmMvdzMyLmMKKysrIGIvc3JjL3czMi5jCkBAIC0xMDU4Niw2ICsxMDU4NiwxMCBAQCBnbG9i YWxzX29mX3czMiAodm9pZCkKICNlbmRpZgogCiAgIHczMl9jcnlwdG9faHByb3YgPSAoSENSWVBU UFJPVikwOworCisgIC8qIFdlIG5lZWQgdG8gZm9yZ2V0IGFib3V0IGxpYnJhcmllcyB0aGF0IHdl cmUgbG9hZGVkIGR1cmluZyB0aGUKKyAgICAgZHVtcGluZyBwcm9jZXNzIChlLmcuIGxpYmdjY2pp dCkgKi8KKyAgVmxpYnJhcnlfY2FjaGUgPSBRbmlsOwogfQogCiAvKiBGb3IgbWFrZS1zZXJpYWwt cHJvY2VzcyAgKi8KZGlmZiAtLWdpdCBhL3NyYy93MzJmbnMuYyBiL3NyYy93MzJmbnMuYwppbmRl eCBlNTk1YjAyODVhLi5lZWI3MzQ4OWRkIDEwMDY0NAotLS0gYS9zcmMvdzMyZm5zLmMKKysrIGIv c3JjL3czMmZucy5jCkBAIC0xMDQ2Miw2ICsxMDQ2Miw3IEBAIHN5bXNfb2ZfdzMyZm5zICh2b2lk KQogICBERUZTWU0gKFF6bGliLCAiemxpYiIpOwogICBERUZTWU0gKFFsY21zMiwgImxjbXMyIik7 CiAgIERFRlNZTSAoUWpzb24sICJqc29uIik7CisgIERFRlNZTSAoUWdjY2ppdCwgImdjY2ppdCIp OwogCiAgIEZwdXQgKFF1bmRlZmluZWRfY29sb3IsIFFlcnJvcl9jb25kaXRpb25zLAogCXB1cmVf bGlzdCAoUXVuZGVmaW5lZF9jb2xvciwgUWVycm9yKSk7Ci0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000d7b75005a616bdaa Content-Type: application/octet-stream; name="0006-Workaround-the-32768-chars-command-line-limit-in-Win.patch" Content-Disposition: attachment; filename="0006-Workaround-the-32768-chars-command-line-limit-in-Win.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kafjv5v55 RnJvbSA1ZDBhZmFlNGYxZWNjMDU3N2JhZjUyNTQ1YjhiNjU2NzY2YTFkMzA0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCA4IE1heSAyMDIwIDE0OjA0 OjA2IC0wMzAwClN1YmplY3Q6IFtQQVRDSCA2LzldIFdvcmthcm91bmQgdGhlIDMyNzY4IGNoYXJz IGNvbW1hbmQgbGluZSBsaW1pdCBpbiBXaW5kb3dzLgoKKiBsaXNwL2VtYWNzLWxpc3AvY29tcC5l bCAoY29tcC1ydW4tYXN5bmMtd29ya2Vycyk6IFBhc3MgdGhlCmNvbXBpbGF0aW9uIGNvbW1hbmRz IHRocm91Z2ggYSB0ZW1wb3JhcnkgZmlsZSB0aGF0IGlzIGxvYWRlZCBieSB0aGUKY2hpbGQgcHJv Y2Vzcy4gVGhpcyBpcyBhbHNvIGRvbmUgYWxsIG90aGVyIG9wZXJhdGluZyBzeXN0ZW1zLCBldmVu CnRob3NlIHRoYXQgc3VwcG9ydCBsb25nIGNvbW1hbmQgbGluZXMuIEl0IHNob3VsZCBub3QgYmUg YSBwcm9ibGVtCnNpbmNlIGxpYmdjY2ppdCB1c2VzIHRlbXBvcmFyeSBmaWxlcyB0b28uCi0tLQog bGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgfCA2ICsrKysrLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5z ZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9j b21wLmVsIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKaW5kZXggYzJhOTVmZWVjMS4uZDMyZjkz YTFlMSAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKKysrIGIvbGlzcC9lbWFj cy1saXNwL2NvbXAuZWwKQEAgLTIyMzksNiArMjIzOSw5IEBAIGNvbXAtcnVuLWFzeW5jLXdvcmtl cnMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWVzc2FnZSAiQ29tcGlsaW5nICVzLi4u IiAsc291cmNlLWZpbGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5hdGl2ZS1jb21w aWxlICxzb3VyY2UtZmlsZSAsKGFuZCBsb2FkIHQpKSkpCiAgICAgICAgICAgICAgICAgICAgKHNv dXJjZS1maWxlMSBzb3VyY2UtZmlsZSkgOzsgTWFrZSB0aGUgY2xvc3VyZSB3b3JrcyA6LworICAg ICAgICAgICAgICAgICAgICh0ZW1wLWZpbGUgKG1ha2UtdGVtcC1maWxlCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGNvbmNhdCAiZW1hY3MtYXN5bmMtY29tcC0iIChmaWxlLW5hbWUt YmFzZSBzb3VyY2UtZmlsZSkgIi0iKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5p bCAiLmVsIiAocHJpbjEtdG8tc3RyaW5nIGV4cHIpKSkKICAgICAgICAgICAgICAgICAgICAobG9h ZDEgbG9hZCkKICAgICAgICAgICAgICAgICAgICAocHJvY2VzcyAobWFrZS1wcm9jZXNzCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDpuYW1lIChjb25jYXQgIkNvbXBpbGluZzogIiBzb3Vy Y2UtZmlsZSkKQEAgLTIyNDYsMTMgKzIyNDksMTQgQEAgY29tcC1ydW4tYXN5bmMtd29ya2Vycwog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6Y29tbWFuZCAobGlzdAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGV4cGFuZC1maWxlLW5hbWUgaW52b2NhdGlvbi1u YW1lCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpbnZvY2F0aW9uLWRpcmVjdG9yeSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICItLWJhdGNoIiAiLS1ldmFsIiAocHJpbjEtdG8tc3RyaW5nIGV4cHIpKQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi0tYmF0Y2giICItbCIgdGVtcC1m aWxlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6c2VudGluZWwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGxhbWJkYSAocHJvY2VzcyBfZXZlbnQpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKHJ1bi1ob29rLXdpdGgtYXJncwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAnY29tcC1hc3luYy1jdS1kb25lLWhvb2sKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc291cmNlLWZpbGUpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGFjY2VwdC1wcm9jZXNzLW91dHB1dCBwcm9jZXNzKQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChpZ25vcmUtZXJyb3JzIChkZWxldGUtZmlsZSB0ZW1wLWZpbGUpKQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICh3aGVuIChhbmQgbG9hZDEKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICh6ZXJvcCAocHJvY2Vzcy1leGl0LXN0YXR1cyBw cm9jZXNzKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobmF0aXZlLWVsaXNw LWxvYWQKLS0gCjIuMjUuMS53aW5kb3dzLjEKCg== --000000000000d7b75005a616bdaa-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 12:44:59 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 16:44:59 +0000 Received: from localhost ([127.0.0.1]:54150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRpy-0008UN-Uz for submit@debbugs.gnu.org; Wed, 20 May 2020 12:44:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbRpx-0008UA-3u for 41242@debbugs.gnu.org; Wed, 20 May 2020 12:44:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53242) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbRpr-0004BN-RX; Wed, 20 May 2020 12:44:51 -0400 Received: from [176.228.60.248] (port=3184 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jbRpq-0000GT-VF; Wed, 20 May 2020 12:44:51 -0400 Date: Wed, 20 May 2020 19:44:51 +0300 Message-Id: <831rne7dz0.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Wed, 13 May 2020 16:26:57 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (---) > From: Nicolas Bértolo > Date: Wed, 13 May 2020 16:26:57 -0300 > > There are a few remaining issues: > > * The loading process is very slow. This is especially annoying when coupled > with autoloading. For example, autoloading Helm may stall Emacs for 5 seconds > in my machine. > > I have thought a possible solution to this problem: load the byte-compiled > file and put the native-compiled version in a list. Then load that list one by > one on an idle-timer, that way the UI freezes should be minimized. This could > reuse the "late loading" machinery implemented for deferred compilation. I believe we didn't investigate this issue well enough to understand what happens and why. Would it be possible to investigate this soon? It could be after the patches are installed. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 13:24:34 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 17:24:34 +0000 Received: from localhost ([127.0.0.1]:54186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbSSI-0001FM-Fh for submit@debbugs.gnu.org; Wed, 20 May 2020 13:24:34 -0400 Received: from mx.sdf.org ([205.166.94.20]:57933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbSSH-0001FE-7f for 41242@debbugs.gnu.org; Wed, 20 May 2020 13:24:33 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KHOVrD006312 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 17:24:31 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KHOVww008693; Wed, 20 May 2020 17:24:31 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Wed, 20 May 2020 17:24:31 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 20 May 2020 13:17:54 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Thanks, I'll start going through them this evening I guess in patch >> chronological order. Ok this is in: 68fad7a8fc @ Do not block SIGIO in platforms that don't have it. Looking at 0003-Handle-setjmp-taking-two-arguments-in-Windows.patch > +static void > +define_setjmp_deps (void) > +{ > + comp.setjmp_ctx_func > + =3D gcc_jit_context_get_builtin_function (comp.ctxt, > + "__builtin_frame_address"); > +} This won't compile on Posix because setjmp_ctx_func is under #ifdef _WIN32. Given setjmp_ctx_func is used only in emit_setjmp I suggest to invoke directly gcc_jit_context_get_builtin_function there while emitting the corresponding call. The following patches do not currently apply, please update them from your rebase branch: 0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch 0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch While you are refreshing patches please have a look into the GNU style of the diff (spaces in function calls and in pointer declaration) ;) Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 13:29:40 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 17:29:40 +0000 Received: from localhost ([127.0.0.1]:54190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbSXE-0001Ms-3P for submit@debbugs.gnu.org; Wed, 20 May 2020 13:29:40 -0400 Received: from mx.sdf.org ([205.166.94.20]:56820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbSXC-0001Mj-Oe for 41242@debbugs.gnu.org; Wed, 20 May 2020 13:29:39 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KHTbKd020727 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 17:29:37 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KHTbZp011484; Wed, 20 May 2020 17:29:37 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Wed, 20 May 2020 17:29:37 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 20 May 2020 13:17:54 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: Sorry, still looking at 0003-Handle-setjmp-taking-two-arguments-in-Windows.patch forgot to ask if you could comment on this change: > comp.char_type, > - sizeof (jmp_buf)), > + sizeof (sys_jmp_buf)), Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 14:00:01 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 18:00:02 +0000 Received: from localhost ([127.0.0.1]:54214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbT0b-0004H9-G0 for submit@debbugs.gnu.org; Wed, 20 May 2020 14:00:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbT0Z-0004Gc-VG for 41242@debbugs.gnu.org; Wed, 20 May 2020 14:00:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54788) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbT0U-0001iu-0Q; Wed, 20 May 2020 13:59:54 -0400 Received: from [176.228.60.248] (port=3798 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jbT0M-0002va-4Q; Wed, 20 May 2020 13:59:52 -0400 Date: Wed, 20 May 2020 20:59:46 +0300 Message-Id: <83y2pm5vxp.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 20 May 2020 17:29:37 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > Date: Wed, 20 May 2020 17:29:37 +0000 > > Sorry, still looking at > 0003-Handle-setjmp-taking-two-arguments-in-Windows.patch forgot to ask > if you could comment on this change: > > > comp.char_type, > > - sizeof (jmp_buf)), > > + sizeof (sys_jmp_buf)), I think the latter is more portable, see lisp.h around line 2150. From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 14:09:58 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 18:09:58 +0000 Received: from localhost ([127.0.0.1]:54233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbTAE-0004YH-2Z for submit@debbugs.gnu.org; Wed, 20 May 2020 14:09:58 -0400 Received: from mx.sdf.org ([205.166.94.20]:64121) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbTAA-0004Y6-5I for 41242@debbugs.gnu.org; Wed, 20 May 2020 14:09:56 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KI9rMH016985 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 18:09:53 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KI9rlQ030245; Wed, 20 May 2020 18:09:53 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> <83y2pm5vxp.fsf@gnu.org> Date: Wed, 20 May 2020 18:09:53 +0000 In-Reply-To: <83y2pm5vxp.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 May 2020 20:59:46 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: > I think the latter is more portable, see lisp.h around line 2150. I see thanks. -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 14:49:34 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 18:49:34 +0000 Received: from localhost ([127.0.0.1]:54251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbTmY-0005ZM-DF for submit@debbugs.gnu.org; Wed, 20 May 2020 14:49:34 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:45703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbTmX-0005ZA-Gx for 41242@debbugs.gnu.org; Wed, 20 May 2020 14:49:33 -0400 Received: by mail-ot1-f66.google.com with SMTP id c3so3353835otr.12 for <41242@debbugs.gnu.org>; Wed, 20 May 2020 11:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TCR22K+LGX0Zq6Tv6B0iEJk3fQoyDALmKv7cUQOCe78=; b=kqmjDXkFvAv0pMN6QpfW3swCoG7tULgEyRe6P1una0FjpmbDT+mjlmpBdYcGBXI8QO tdnzd4uI6LcMCyrltscg402e86YKHPuAEIkZ8mD3i4/dyl6EUITUQsRVDAo+lbu+MdQ2 6V5NVLHEiZNv/FXVKA6k9hpWjfW8v3DJhJn1obePy0g7mEQaq3rDIUB/uw2pwYH9z2mR qUAM6fLnQ239E5fa6VIPO5JAuMOGOz7+VMLtXUnPgpzr2SN7WOCcHW3E0cGTpUsrF5Qq 2vHU1hq5FiEcCbZEjt06R6hhbI0v+RarVq+bnBEiw1ydZFPNFSHKJ59/k5Zfm9/+vnXI oJqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TCR22K+LGX0Zq6Tv6B0iEJk3fQoyDALmKv7cUQOCe78=; b=oKrfXHvTLmTUIBi5k3Dphgcgo9CLaR/o/UKgN87VHh6bFupFx1HLsne2DTZgMMkT1M QXfkUur4OQiNchHM9DwSFUMl4Rw3XaqclxPG7OkIDMsg7HVE4ZFAOC9CUS9nBtgycg89 hG87RRTUH+NYz0/xY02KLCX9RRZ9vXBI4aUopUEODidRaI8VOK1Z0FmlA0B5opZawLFw 7+XwhLn7F3a9j9zq2+B8pq1o9R5XNukfwI7Vfq14TFEtFFEMcSWi1kLk8VuYOIn2/IX9 rSLE4iP+Q+HlI3jMjpq/3dHREZhEWxqRvwJNDqelizieoq1CsiZfrmemN6AqTSADpZg9 O7Aw== X-Gm-Message-State: AOAM530ka9bDHY2WCOpuI3MZ2/aph0e1QaypNyNY7qNaYXJY1W4sVo5u 0he3M2PgjtIg77sVtu4D+9S17ioUaVT3nZDk9Yg= X-Google-Smtp-Source: ABdhPJz84AehPakE+ZPS9zCWi904d6y2iJxZ4QgerI/PJ1syhSnFIFe/XvO1T/oS2ErKfBszd1JKCBfbHsoIrHUGpbw= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr4486041oon.22.1590000567622; Wed, 20 May 2020 11:49:27 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 20 May 2020 15:48:52 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: multipart/alternative; boundary="00000000000006a0c705a618dbb0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) --00000000000006a0c705a618dbb0 Content-Type: text/plain; charset="UTF-8" > This won't compile on Posix because setjmp_ctx_func is under #ifdef > _WIN32. Fixed. > Given setjmp_ctx_func is used only in emit_setjmp I suggest to invoke > directly gcc_jit_context_get_builtin_function there while emitting the > corresponding call. Done. > The following patches do not currently apply, please update them from > your rebase branch: > 0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch > 0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch Done. > While you are refreshing patches please have a look into the GNU style > of the diff (spaces in function calls and in pointer declaration) ;) Fixed :). > Sorry, still looking at > 0003-Handle-setjmp-taking-two-arguments-in-Windows.patch forgot to ask > if you could comment on this change: > > comp.char_type, > > - sizeof (jmp_buf)), > > + sizeof (sys_jmp_buf)), It is just a little bit more portable. I uploaded new patches to https://github.com/nicber/emacs branch feature/native-comp. Please tell me I if you'd rather I posted patches here. --00000000000006a0c705a618dbb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This won't compile on Posix because setjmp_ctx_fu= nc is under #ifdef
> _WIN32.

Fixed.

> Given setjmp_c= tx_func is used only in emit_setjmp I suggest to invoke
> directly gc= c_jit_context_get_builtin_function there while emitting the
> corresp= onding call.

Done.

> The following patches do not currentl= y apply, please update them from
> your rebase branch:

> 00= 04-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch
> 0005-= Remove-a-layer-of-indirection-for-access-to-pure-sto.patch

Done.
=
> While you are refreshing patches please have a look into the GNU s= tyle
> of the diff (spaces in function calls and in pointer declarati= on) ;)

Fixed :).

> Sorry, still looking at
> 0003-Ha= ndle-setjmp-taking-two-arguments-in-Windows.patch forgot to ask
> if = you could comment on this change:
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 comp.char_type,
> > - =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 sizeof (jmp_buf)),
> > + =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sizeof (sys_jmp_buf)),

It is just a = little bit more portable.

I uploaded new patches to https://github.com/nicber/emacs branch
f= eature/native-comp. Please tell me I if you'd rather I posted patches h= ere.
--00000000000006a0c705a618dbb0-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 17:38:42 2020 Received: (at 41242) by debbugs.gnu.org; 20 May 2020 21:38:42 +0000 Received: from localhost ([127.0.0.1]:54519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbWQD-0005n6-Rn for submit@debbugs.gnu.org; Wed, 20 May 2020 17:38:42 -0400 Received: from mx.sdf.org ([205.166.94.20]:60056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbWQB-0005mu-E0 for 41242@debbugs.gnu.org; Wed, 20 May 2020 17:38:40 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04KLcbvv007231 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 20 May 2020 21:38:37 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04KLcbPD008743; Wed, 20 May 2020 21:38:37 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Wed, 20 May 2020 21:38:37 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 20 May 2020 15:48:52 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > I uploaded new patches to https://github.com/nicber/emacs branch > feature/native-comp. Please tell me I if you'd rather I posted > patches here. Git works for me thanks. I've pushed 05b08f2644 * Handle setjmp() taking two arguments in Windows. 5ff2cbdb04 * Remove a layer of indirection for access to pure storage. I took the freedom to do myself some minors to avoid a re-spin, you can have a look. I started testing Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT because is sensitive. The space of the configurations is relatively big and I want to cover the one I can here so I think I'll be done tomorrow. Thanks Andrea PS are you cooking-up also libgccjit patches? --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed May 20 21:58:50 2020 Received: (at 41242) by debbugs.gnu.org; 21 May 2020 01:58:51 +0000 Received: from localhost ([127.0.0.1]:54853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbaTy-0006Cc-OI for submit@debbugs.gnu.org; Wed, 20 May 2020 21:58:50 -0400 Received: from mail-ot1-f46.google.com ([209.85.210.46]:45454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbaTx-0006CQ-96 for 41242@debbugs.gnu.org; Wed, 20 May 2020 21:58:49 -0400 Received: by mail-ot1-f46.google.com with SMTP id c3so4292243otr.12 for <41242@debbugs.gnu.org>; Wed, 20 May 2020 18:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4MqY6xPgaQhvxNTFa0ZD6wrFNg8hsRk1XxGkm1F8tjc=; b=GXZnFBshm5kn+FlHw1sVwHE5IpKW6VBd/KJkrBAVgj+KGXics1CT/wMCCTObtQEyP2 qQiTtUrbmAW3Ep7TXJIil/8KMRt07q5YP0OIu9ZrL/Yqm64cGKUePtjXGvfU9Q7zqiQr x4lVC7Rd+pY664lZJwcksouQ8QV3J5xf1cuX+jhE+CIllwoSWEl5ubJfd20GGET4nMpq sD624NL+yzJqyDW9fJAbigW6/9QtQ2roBK6dcoryKF0s/suUG1goS243Ila26kQOzXwk 23YTo4s0xUKAWnh1paBt/rkyCHMQIko2nsP9fN6rpDASIJTrClbgOhOeCbHHOSkQEC3/ 3E3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4MqY6xPgaQhvxNTFa0ZD6wrFNg8hsRk1XxGkm1F8tjc=; b=F7+2dQtQ9scRzzHCWiyTZ1jiPbGYQcbkw0knPU4zQgFsq5PrAeeYogu3NdueyYrfv/ kefsMEpzeJH9VoZUq2Xt3d6zrLGFMe/huVt5EOYYJIFwcqxY9TM6yb7gifAgAhxgCstr BSZES34eKPTf7Uuz35WVoZrBMAk2TbDL6HKuZfk9ifTQws4+pxNgY4y5nZSaUFu2/5vV BqGBMIgt6XdcDpnKaO4KSwNN4EZic/Ffcvolw4qp0homrvql+dyO9eI5XcxA7GTIu1/X 7CJywrFkOnDvI8oL2s/ez2iiX1YljkkHgWM4Q8EVPX7OVBfOcnkyC9Dphs65spwDoN9W JP7Q== X-Gm-Message-State: AOAM530Rhh8QDTZmqAS3YQ+mMTbAd6GP+D0dWdeBaVEa0Oe4EyWRHP9F SvP0ddO0/JqzDsKxDk+oWuV7Lk4ZQFJaqFMRTzY= X-Google-Smtp-Source: ABdhPJwZolUaFCWi4iDxnesroSV3wvMQ6kpnlqAHSaE+QWDx6QnM6B+m/X4L4Q+Ulvf6cgi8a5B2Nv+39VD+UrjLzR4= X-Received: by 2002:a9d:191:: with SMTP id e17mr5147394ote.193.1590026323346; Wed, 20 May 2020 18:58:43 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 20 May 2020 22:58:28 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: multipart/alternative; boundary="0000000000002fc95005a61eda0a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) --0000000000002fc95005a61eda0a Content-Type: text/plain; charset="UTF-8" > PS are you cooking-up also libgccjit patches? Yes, the C++ side is done. I need help with the build system side of things. * libiberty.a needs to be copied by hand between folders inside the build directory. * libgccjit.dll does not get created in the "bin" folder. It is created as libgccjit.so.0.0.1 in the "lib" folder, so it needs to copied and renamed. Nicolas --0000000000002fc95005a61eda0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> PS are you cooking-up also libgccjit patches?<= br>
Yes, the C++ side is done.
I need help with= the build system side of things.
* libiberty.a needs to be copie= d by hand between folders inside the build directory.
* libgc= cjit.dll does not get created in the "bin" folder.
=C2= =A0 It is created as libgccjit.so.0.0.1 in the "lib" folder, so i= t needs to copied and renamed.

Nicolas
--0000000000002fc95005a61eda0a-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 21 14:51:09 2020 Received: (at 41242) by debbugs.gnu.org; 21 May 2020 18:51:09 +0000 Received: from localhost ([127.0.0.1]:57275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbqHd-0003zI-EB for submit@debbugs.gnu.org; Thu, 21 May 2020 14:51:09 -0400 Received: from mx.sdf.org ([205.166.94.20]:61224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbqHZ-0003z4-7v for 41242@debbugs.gnu.org; Thu, 21 May 2020 14:51:07 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04LIp3lI004048 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 21 May 2020 18:51:03 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04LIp35o002859; Thu, 21 May 2020 18:51:03 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Thu, 21 May 2020 18:51:03 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 20 May 2020 22:58:28 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) I keep on working on top of "Handle LISP_WORDS_ARE_POINTERS and CHECK_LISP_OBJECT_TYPE". The x86_64 works like a charm and compile time is not affected. I did some fixing for i386 --enable-check-lisp-object-type, now I'm on wide-int where we get ICE in GCC. Hope to sort out quickly but can't guarantee. Nicolas B=C3=A9rtolo writes: >> PS are you cooking-up also libgccjit patches? > Yes, the C++ side is done. > I need help with the build system side of things. > * libiberty.a needs to be copied by hand between folders inside the > build directory. > * libgccjit.dll does not get created in the "bin" folder. > =C2=A0 It is created as libgccjit.so.0.0.1 in the "lib" folder, so it > needs to copied and renamed. Yeah build system is always tricky, but I guess defining a new target to rename and copy or modifying the existing one for the new name should not be a problem no? If you need help the better place to ask and discuss is jit@gcc.gnu.org tho. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Fri May 22 17:23:42 2020 Received: (at 41242) by debbugs.gnu.org; 22 May 2020 21:23:42 +0000 Received: from localhost ([127.0.0.1]:60575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcF8n-0001Ij-Uv for submit@debbugs.gnu.org; Fri, 22 May 2020 17:23:42 -0400 Received: from mx.sdf.org ([205.166.94.20]:65104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcF8j-0001IX-2R for 41242@debbugs.gnu.org; Fri, 22 May 2020 17:23:40 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04MLNZ1x009294 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 22 May 2020 21:23:36 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04MLNZDm027119; Fri, 22 May 2020 21:23:35 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> Date: Fri, 22 May 2020 21:23:35 +0000 In-Reply-To: (Andrea Corallo's message of "Thu, 21 May 2020 18:51:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) I've installed "Handle LISP_WORDS_ARE_POINTERS..." plus some fixes mostly unrelated. We still ICE GCC (at least my 10 and trunk) on i386 at speed 2 with --enable-check-lisp-object-type. This really looks like a libgccjit bug. Tomorrow I'll try to look into it better and to progress into applying patches. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Fri May 22 21:56:53 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 01:56:53 +0000 Received: from localhost ([127.0.0.1]:33143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcJPB-0007xx-33 for submit@debbugs.gnu.org; Fri, 22 May 2020 21:56:53 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:46810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcJP8-0007xj-Ox for 41242@debbugs.gnu.org; Fri, 22 May 2020 21:56:51 -0400 Received: by mail-ot1-f48.google.com with SMTP id g25so9667530otp.13 for <41242@debbugs.gnu.org>; Fri, 22 May 2020 18:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eLEdj23dNO4MsihYjvWt7C73PFjAHzENeY8AZKBr9Jo=; b=Ju+HbvY76h6vx/uRze09LOcsVqWShprO2dmnR9FzXgr5+zJVs3RzXqOXhSQq4LATLZ 0shSy01i/OCu0RL9dy2fv3lGg0YMy6EdmRq6rYomS05UOZcc3YZmWLRhZXRtS4SPhyw6 Xum0zMNeGx4ukgCT/h06WyQ01JEMOQsE+hspODsDzfSIFwYlGvD7NrNwJgdVtDxWFRJq cET9RfPNH1LsbA9HCacXfarWQ5rSYgrtYhMuyVBGPhNcBTCR0KsIEirfayZ2L9hL4Bw6 ECt0uwHChJ4irL5BhTetAEG42Mk2+vBiZN+Nhhi1nd84BKwMqAD2wxIAb6rp3van8PI1 Pabw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eLEdj23dNO4MsihYjvWt7C73PFjAHzENeY8AZKBr9Jo=; b=GemlgihYn3BOpoASetTafkgZNSKLrM8z+j3zugarISQgN4P38lo9PkCamThPfAtkid F9S9oK6C/DdpSku20dDBu4UKBKSWwMaVHo30DuvGh9ZYlc31qv5UMrdkmIcKpCgnB0y1 2wpEPTrQCHbMTwg+0ZTsg9CvTT29QATww9GunnDLLZ4YDtXNBWRyC+cKenajbdI3DAzh UfaZR75vhutSaMPL260/xS0mH+l1To9xr/NztNR2SeG9wC/jSodqHDxUMX2F95wVUfax hQuabhBe6xt1UgRnTkUdLUdj+i1dvmV/Mrq8ejkTl2EUK0vT399GlygIdCeJcmkg0yIA liXA== X-Gm-Message-State: AOAM531rpelHiJdraCViDDUOcP+nSGoFlJLSDDp155x/q+zkO+VF8hGD 1hxLbij23H37yqavASClFAFPBafHKAaEaf71mC0= X-Google-Smtp-Source: ABdhPJyBRRx6aBMPcIX17l6Y2gpIY7gQDo4T/bCBPg8oM1QAB+hB2dJw+Me+M1Fy+7Zt1gN+E5lWEMyzEiSAYiizCIA= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr13003629oti.202.1590199004977; Fri, 22 May 2020 18:56:44 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Fri, 22 May 2020 22:56:32 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo , Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d05ca405a6470e6f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000d05ca405a6470e6f Content-Type: text/plain; charset="UTF-8" >> I have thought a possible solution to this problem: load the byte-compiled >> file and put the native-compiled version in a list. Then load that list one by >> one on an idle-timer, that way the UI freezes should be minimized. This could >> reuse the "late loading" machinery implemented for deferred compilation. > I believe we didn't investigate this issue well enough to understand > what happens and why. Would it be possible to investigate this soon? > It could be after the patches are installed. I profiled Emacs and found out that most of the time it was blocked on a call to wopen(). A non-native-comp build will try to open these files in each path in `load-path': - foo.dll.gz - foo.dll.gz - foo.elc.gz - foo.elc - foo.el.gz - foo.el The native-comp build with try to open these files instead: - eln-$HASH/foo.eln - eln-$HASH/foo.eln.gz - eln-$HASH/foo.dll - eln-$HASH/foo.dll.gz - eln-$HASH/foo.elc - eln-$HASH/foo.elc.gz - eln-$HASH/foo.el - eln-$HASH/foo.el.gz - foo.eln - foo.eln.gz - foo.dll - foo.dll.gz - foo.elc - foo.elc.gz - foo.el - foo.el.gz This is a 166% percent increase in calls to wopen(). Moreover, it is trying to open some files that don't make sense (*.dll.gz and *.eln.gz) and it's testing the eln-$HASH directory for *.el and *.elc files. This is what is should be probing: - eln-$HASH/foo.eln (only native-comp) - foo.eln (only native-comp) - foo.dll - foo.elc - foo.elc.gz - foo.el - foo.el.gz This is "only" a 40% increase. I don't think we can do much better here. That is, unless we implement some kind of cache, but that would be an extreme solution. This problem shows in Windows because the NT kernel is slow at file access (See https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829). The same thing happens to Git for Windows in my experience. --000000000000d05ca405a6470e6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>=C2=A0 =C2=A0I have thought a possible solution to this problem: lo= ad the byte-compiled
>>=C2=A0 =C2=A0file and put the native-compil= ed version in a list. Then load that list one by
>>=C2=A0 =C2=A0on= e on an idle-timer, that way the UI freezes should be minimized. This could=
>>=C2=A0 =C2=A0reuse the "late loading" machinery imple= mented for deferred compilation.

> I believe we didn't invest= igate this issue well enough to understand
> what happens and why.=C2= =A0 Would it be possible to investigate this soon?
> It could be afte= r the patches are installed.

I profiled Emacs and found out that mos= t of the time it was blocked on a call to
wopen().

A non-native-c= omp build will try to open these files in each path in
`load-path':<= br>
- foo.dll.gz
- foo.dll.gz
- foo.elc.gz
- foo.elc
- foo.e= l.gz
- foo.el

The native-comp build with try to open these files = instead:

- eln-$HASH/foo.eln
- eln-$HASH/foo.eln.gz
- eln-$HAS= H/foo.dll
- eln-$HASH/foo.dll.gz
- eln-$HASH/foo.elc
- eln-$HASH/f= oo.elc.gz
- eln-$HASH/foo.el
- eln-$HASH/foo.el.gz
- foo.eln
- = foo.eln.gz
- foo.dll
- foo.dll.gz
- foo.elc
- foo.elc.gz
- f= oo.el
- foo.el.gz

This is a 166% percent increase in calls to wop= en(). Moreover, it is trying to
open some files that don't make sens= e (*.dll.gz and *.eln.gz) and it's testing
the eln-$HASH directory f= or *.el and *.elc files.

This is what is should be probing:

-= eln-$HASH/foo.eln (only native-comp)
- foo.eln (only native-comp)
- = foo.dll
- foo.elc
- foo.elc.gz
- foo.el
- foo.el.gz

This= is "only" a 40% increase. I don't think we can do much bette= r here. That
is, unless we implement some kind of cache, but that would = be an extreme
solution.

This problem shows in Windows because the= NT kernel is slow at file access (See
https://github.com/Microsoft/= WSL/issues/873#issuecomment-425272829).

The same thing happens t= o Git for Windows in my experience.
--000000000000d05ca405a6470e6f-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 00:41:32 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 04:41:32 +0000 Received: from localhost ([127.0.0.1]:33217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcLyW-0003fz-JS for submit@debbugs.gnu.org; Sat, 23 May 2020 00:41:32 -0400 Received: from mail-oi1-f173.google.com ([209.85.167.173]:45325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcLyU-0003fm-QG for 41242@debbugs.gnu.org; Sat, 23 May 2020 00:41:31 -0400 Received: by mail-oi1-f173.google.com with SMTP id d191so11112815oib.12 for <41242@debbugs.gnu.org>; Fri, 22 May 2020 21:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2S+U26UwIXBAJd1P0qjpvV0rSS7fA+efep/FRUoQ0Kg=; b=Uw3k3NdmCefIGyRYo+PG3xl5yT0t0DhhYWZZ1NKBTLbfH2eIMaHcejK0ou40E2lPqd dtB6XKz/EnP284AwfNvk3s2or7uDOptaRLebxfVLjDMUzHwPV1d/fnS6wGSI99Lqh3NA stxNovdEEmcshGCPCvXHd9XYhEChe9AzHP/HMlLwvA3miwSXC+XT+xYDh/GAoo87YEke ekF1bT8aj6ckqHJqfBXbcRGA1Zg3sFc3HSCVAIbd8NV3UecdHEDO8r30E/8mNcp67w7S nXNI7JCrFKhGfsb/VrnOTb9WqsnwMFNia34F14e7kG54QPwoTqFftXboSvZY8qBpR9DQ VTZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2S+U26UwIXBAJd1P0qjpvV0rSS7fA+efep/FRUoQ0Kg=; b=k2QGopL66MhV5eyoeDgh2k34/aeGiMujvaJjmFXZQEqWTj7cVEyyIefhzyWzMIuMX5 FjwsEy5DnMYKb7JnqqAMQl13m3Cv902M0rGUqM/ZdGexf3HwWIcSaUDgnp22dcXZ1KAC M3awBjh0L+d6DEZUpM6wMrRgZckhoX7WP3dkcMxt+Ee3qwdMTbG7smOT5EP153jievRS cRpEEPPG6rTVm9ycvVxc2HKB+Ygxub2tPGRf1Oqzgbgt/PcejnpelSnvP4lv1+7vTqpN 9Gnp95Bg0VUl5h+RblkWAPM7I+ekCEoD7K6J72SBOXqa+w+Qz8GQcEsia9iNuvlopmo4 16GA== X-Gm-Message-State: AOAM530Z6CdLE1RaYV2n/4ULF8k3eBRQmDoEqPI9jfj0pPj4mT6zjAim vG/aVl1KowLN4RjyVE8elCit1ptknXzcb0KoFGs= X-Google-Smtp-Source: ABdhPJxNUoJd7IrJLJDUnWSxk+L/GBfdrNvZCV6gcycs7E86dvb0lpVE5YlpfE54gFyFtFaUWqHI/cRK0G3cG1N2/Ww= X-Received: by 2002:a54:4701:: with SMTP id k1mr4876483oik.175.1590208884947; Fri, 22 May 2020 21:41:24 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <838shm7g9m.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 01:41:11 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo , Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000b5c30505a6495b1d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000b5c30505a6495b1d Content-Type: text/plain; charset="UTF-8" > This is what is should be probing: > - eln-$HASH/foo.eln (only native-comp) > - foo.eln (only native-comp) > - foo.dll > - foo.elc > - foo.elc.gz > - foo.el > - foo.el.gz I did a quick test and make openp() only call emacs_open() when a file matches one in the list above. This cut Emacs startup time by half! This seems promising. Nicolas --000000000000b5c30505a6495b1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=20 This is what is should be probing:

> - eln-$HASH/foo.eln (only na= tive-comp)
>=20 - foo.eln (only native-comp)
>=20 - foo.dll
>=20 - foo.elc
>=20 - foo.elc.gz
>=20 - foo.el
>=20 - foo.el.gz

I did a quick test and make openp() on= ly call emacs_open() when a file matches one in the list above.
T= his cut Emacs startup time by half! This seems promising.

Nicolas

--000000000000b5c30505a6495b1d-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 04:07:23 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 08:07:23 +0000 Received: from localhost ([127.0.0.1]:33341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcPBj-0002WQ-Ez for submit@debbugs.gnu.org; Sat, 23 May 2020 04:07:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcPBh-0002WE-Cl for 41242@debbugs.gnu.org; Sat, 23 May 2020 04:07:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40202) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcPBb-0003NL-Kt; Sat, 23 May 2020 04:07:15 -0400 Received: from [176.228.60.248] (port=3035 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcPBb-0001fS-0C; Sat, 23 May 2020 04:07:15 -0400 Date: Sat, 23 May 2020 11:07:22 +0300 Message-Id: <83blmf13d1.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Wed, 20 May 2020 12:46:32 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Wed, 20 May 2020 12:46:32 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > When loading a dump file that contains native compiled elisp we try to find the > .eln file. This uses Ffile_exists_p(). This function, in turn, calls > Fexpand_file_name(). This function will use the root directory as > `default_directory' as a fallback. > > Getting the root directory requires reading the $emacs_dir environment variable. > This is setup later in the initialization process. This caused a crash. Can you tell why this doesn't happen when *.elc files are used instead? Also, what do you mean by "loading a dump file that contains native compiled elisp"? how did native compiled ELisp get into the dump file in the first place? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 04:35:47 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 08:35:47 +0000 Received: from localhost ([127.0.0.1]:33366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcPdC-0003Dh-RR for submit@debbugs.gnu.org; Sat, 23 May 2020 04:35:47 -0400 Received: from mx.sdf.org ([205.166.94.20]:54301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcPdB-0003DU-0a for 41242@debbugs.gnu.org; Sat, 23 May 2020 04:35:45 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04N8Zh4H027888 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 08:35:44 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04N8ZhT8015667; Sat, 23 May 2020 08:35:43 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> Date: Sat, 23 May 2020 08:35:43 +0000 In-Reply-To: <83blmf13d1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 11:07:22 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: >> From: Nicolas B=C3=A9rtolo >> Date: Wed, 20 May 2020 12:46:32 -0300 >> Cc: Andrea Corallo , 41242@debbugs.gnu.org >>=20 >> When loading a dump file that contains native compiled elisp we try to f= ind the >> .eln file. This uses Ffile_exists_p(). This function, in turn, calls >> Fexpand_file_name(). This function will use the root directory as >> `default_directory' as a fallback. >>=20 >> Getting the root directory requires reading the $emacs_dir environment v= ariable. >> This is setup later in the initialization process. This caused a crash. > > Can you tell why this doesn't happen when *.elc files are used > instead? Also, what do you mean by "loading a dump file that contains > native compiled elisp"? how did native compiled ELisp get into the > dump file in the first place? Hi Eli, you may be interested in this paragraph https://akrl.sdf.org/gccemacs.html#orgb063106 Regards Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 05:22:50 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 09:22:50 +0000 Received: from localhost ([127.0.0.1]:33427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcQMk-0004Si-JT for submit@debbugs.gnu.org; Sat, 23 May 2020 05:22:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcQMi-0004SS-Rb for 41242@debbugs.gnu.org; Sat, 23 May 2020 05:22:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40923) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcQMd-0007nO-BC; Sat, 23 May 2020 05:22:43 -0400 Received: from [176.228.60.248] (port=3760 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcQMc-00083u-HP; Sat, 23 May 2020 05:22:43 -0400 Date: Sat, 23 May 2020 12:22:48 +0300 Message-Id: <83367r0zvb.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Sat, 23 May 2020 08:35:43 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: Nicolas Bértolo , > 41242@debbugs.gnu.org > Date: Sat, 23 May 2020 08:35:43 +0000 > > >> When loading a dump file that contains native compiled elisp we try to find the > >> .eln file. This uses Ffile_exists_p(). This function, in turn, calls > >> Fexpand_file_name(). This function will use the root directory as > >> `default_directory' as a fallback. > >> > >> Getting the root directory requires reading the $emacs_dir environment variable. > >> This is setup later in the initialization process. This caused a crash. > > > > Can you tell why this doesn't happen when *.elc files are used > > instead? Also, what do you mean by "loading a dump file that contains > > native compiled elisp"? how did native compiled ELisp get into the > > dump file in the first place? > > Hi Eli, > > you may be interested in this paragraph > > https://akrl.sdf.org/gccemacs.html#orgb063106 Thanks. I guess this changes a lot in how Emacs starts up? E.g., what happens if the .el file was in the meantime modified and recompiled into the .eln file? we will load the new versions instead of the one that was preloaded, right? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 06:37:25 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 10:37:25 +0000 Received: from localhost ([127.0.0.1]:33452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcRWu-0006Rg-Qa for submit@debbugs.gnu.org; Sat, 23 May 2020 06:37:25 -0400 Received: from mx.sdf.org ([205.166.94.20]:63034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcRWs-0006RU-QK for 41242@debbugs.gnu.org; Sat, 23 May 2020 06:37:23 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NAbJvt014784 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 10:37:19 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NAbIea011467; Sat, 23 May 2020 10:37:18 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> Date: Sat, 23 May 2020 10:37:18 +0000 In-Reply-To: <83367r0zvb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 12:22:48 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> From: Andrea Corallo >> Cc: Nicolas B=C3=A9rtolo , >> 41242@debbugs.gnu.org >> Date: Sat, 23 May 2020 08:35:43 +0000 >>=20 >> >> When loading a dump file that contains native compiled elisp we try t= o find the >> >> .eln file. This uses Ffile_exists_p(). This function, in turn, calls >> >> Fexpand_file_name(). This function will use the root directory as >> >> `default_directory' as a fallback. >> >>=20 >> >> Getting the root directory requires reading the $emacs_dir environmen= t variable. >> >> This is setup later in the initialization process. This caused a cras= h. >> > >> > Can you tell why this doesn't happen when *.elc files are used >> > instead? Also, what do you mean by "loading a dump file that contains >> > native compiled elisp"? how did native compiled ELisp get into the >> > dump file in the first place? >>=20 >> Hi Eli, >>=20 >> you may be interested in this paragraph >>=20 >> https://akrl.sdf.org/gccemacs.html#orgb063106 > > Thanks. I guess this changes a lot in how Emacs starts up? E.g., > what happens if the .el file was in the meantime modified and > recompiled into the .eln file? we will load the new versions instead > of the one that was preloaded, right? This is something we have to define. Currently we only complain if one of the defined functions that was dumped cannot be found in the new .eln. My preference would be to sign each .eln used for dump to make sure what we are loading is what we dumped and refuse to load otherwise. BTW reloading from dump the "dumped" eln are not located by searching in the load-path for all suffix. The eln position is stored into the compilation unit object for performance reasons. The performance problem Nicolas is discussing is related to the non dumped .elns loaded at startup I believe. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 07:03:38 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 11:03:38 +0000 Received: from localhost ([127.0.0.1]:33471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcRwH-00073Z-Pb for submit@debbugs.gnu.org; Sat, 23 May 2020 07:03:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcRwF-00073L-FY for 41242@debbugs.gnu.org; Sat, 23 May 2020 07:03:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41649) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcRwA-00086Y-5b; Sat, 23 May 2020 07:03:30 -0400 Received: from [176.228.60.248] (port=2269 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcRw8-00011d-7D; Sat, 23 May 2020 07:03:29 -0400 Date: Sat, 23 May 2020 14:03:35 +0300 Message-Id: <83zh9yzzeg.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Sat, 23 May 2020 10:37:18 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org > Date: Sat, 23 May 2020 10:37:18 +0000 > > >> https://akrl.sdf.org/gccemacs.html#orgb063106 > > > > Thanks. I guess this changes a lot in how Emacs starts up? E.g., > > what happens if the .el file was in the meantime modified and > > recompiled into the .eln file? we will load the new versions instead > > of the one that was preloaded, right? > > This is something we have to define. Currently we only complain if one > of the defined functions that was dumped cannot be found in the new > .eln. My preference would be to sign each .eln used for dump to make > sure what we are loading is what we dumped and refuse to load otherwise. > > BTW reloading from dump the "dumped" eln are not located by searching in > the load-path for all suffix. The eln position is stored into the > compilation unit object for performance reasons. Are you saying we store the absolute file name of the .eln files in the pdumper file? If so, how can Emacs start up if the .eln files were moved to another location, e.g. as part of "make install", or more generally if Emacs was relocated since it was dumped? > The performance problem Nicolas is discussing is related to the non > dumped .elns loaded at startup I believe. This is not about the performance issue, this is about the crash because emacs_dir was not yet defined where Emacs needed it: a different issue uncovered by Nicolas. From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 07:21:10 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 11:21:10 +0000 Received: from localhost ([127.0.0.1]:33522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcSDF-0007WA-NF for submit@debbugs.gnu.org; Sat, 23 May 2020 07:21:10 -0400 Received: from mx.sdf.org ([205.166.94.20]:56738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcSDB-0007Vz-Dt for 41242@debbugs.gnu.org; Sat, 23 May 2020 07:21:08 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NBL4Oj007930 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 11:21:04 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NBL3W5003045; Sat, 23 May 2020 11:21:03 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83zh9yzzeg.fsf@gnu.org> Date: Sat, 23 May 2020 11:21:03 +0000 In-Reply-To: <83zh9yzzeg.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 14:03:35 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> From: Andrea Corallo >> Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org >> Date: Sat, 23 May 2020 10:37:18 +0000 >> >> >> https://akrl.sdf.org/gccemacs.html#orgb063106 >> > >> > Thanks. I guess this changes a lot in how Emacs starts up? E.g., >> > what happens if the .el file was in the meantime modified and >> > recompiled into the .eln file? we will load the new versions instead >> > of the one that was preloaded, right? >> >> This is something we have to define. Currently we only complain if one >> of the defined functions that was dumped cannot be found in the new >> .eln. My preference would be to sign each .eln used for dump to make >> sure what we are loading is what we dumped and refuse to load otherwise. >> >> BTW reloading from dump the "dumped" eln are not located by searching in >> the load-path for all suffix. The eln position is stored into the >> compilation unit object for performance reasons. > > Are you saying we store the absolute file name of the .eln files in > the pdumper file? If so, how can Emacs start up if the .eln files > were moved to another location, e.g. as part of "make install", or > more generally if Emacs was relocated since it was dumped? To be precise we store the relative path of the .eln from the emacs executable, both for the local build both for the file position we will have after a "make install". Reloading the first compilation unit the code detect in which of this two cases we are (this is where file-exists is called) and this information is used for all the following compilaiton unit to be revived. >> The performance problem Nicolas is discussing is related to the non >> dumped .elns loaded at startup I believe. > > This is not about the performance issue, this is about the crash > because emacs_dir was not yet defined where Emacs needed it: a > different issue uncovered by Nicolas. Ops got confused between the two branches of this same thread. -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 08:20:08 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 12:20:08 +0000 Received: from localhost ([127.0.0.1]:33582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcT8J-0004ih-TC for submit@debbugs.gnu.org; Sat, 23 May 2020 08:20:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcT8H-0004i3-JN for 41242@debbugs.gnu.org; Sat, 23 May 2020 08:20:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42359) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcT8A-0003KG-TT; Sat, 23 May 2020 08:19:58 -0400 Received: from [176.228.60.248] (port=3396 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcT8A-0005hn-CH; Sat, 23 May 2020 08:19:58 -0400 Date: Sat, 23 May 2020 15:20:06 +0300 Message-Id: <83v9kmzvux.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Sat, 23 May 2020 11:21:03 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83zh9yzzeg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org > Date: Sat, 23 May 2020 11:21:03 +0000 > > >> BTW reloading from dump the "dumped" eln are not located by searching in > >> the load-path for all suffix. The eln position is stored into the > >> compilation unit object for performance reasons. > > > > Are you saying we store the absolute file name of the .eln files in > > the pdumper file? If so, how can Emacs start up if the .eln files > > were moved to another location, e.g. as part of "make install", or > > more generally if Emacs was relocated since it was dumped? > > To be precise we store the relative path of the .eln from the emacs > executable, both for the local build both for the file position we will > have after a "make install". > > Reloading the first compilation unit the code detect in which of this > two cases we are (this is where file-exists is called) and this > information is used for all the following compilaiton unit to be > revived. Do we indeed have only 2 use cases regarding the relative file name of .eln files, and not more? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 08:54:52 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 12:54:52 +0000 Received: from localhost ([127.0.0.1]:33649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcTfw-0005Zy-MS for submit@debbugs.gnu.org; Sat, 23 May 2020 08:54:52 -0400 Received: from mx.sdf.org ([205.166.94.20]:52825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcTfu-0005Zn-S8 for 41242@debbugs.gnu.org; Sat, 23 May 2020 08:54:51 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NCsmmb024575 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 12:54:48 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NCsl1O019518; Sat, 23 May 2020 12:54:47 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83zh9yzzeg.fsf@gnu.org> <83v9kmzvux.fsf@gnu.org> Date: Sat, 23 May 2020 12:54:47 +0000 In-Reply-To: <83v9kmzvux.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 15:20:06 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> To be precise we store the relative path of the .eln from the emacs >> executable, both for the local build both for the file position we will >> have after a "make install". >> >> Reloading the first compilation unit the code detect in which of this >> two cases we are (this is where file-exists is called) and this >> information is used for all the following compilaiton unit to be >> revived. > > Do we indeed have only 2 use cases regarding the relative file name of > .eln files, and not more? If is a question regarding the current implementation of the branch the answer is yes. If is a more generic question then the answer is AFAIK yes, but we could add others if they are known at compile time and needed. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 10:41:38 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 14:41:38 +0000 Received: from localhost ([127.0.0.1]:35293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcVLG-0004SR-BW for submit@debbugs.gnu.org; Sat, 23 May 2020 10:41:38 -0400 Received: from mail-oi1-f170.google.com ([209.85.167.170]:35391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcVLE-0004SD-Nu for 41242@debbugs.gnu.org; Sat, 23 May 2020 10:41:37 -0400 Received: by mail-oi1-f170.google.com with SMTP id z9so7075774oid.2 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 07:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YHATpWMaMVRwsK53UgPwyPtOK4S9tCP7w+KQf5HKEUE=; b=CKbXUVvMtMmeufNq3EWr5i7NAXGt5f4pYNTtx/grTVK9SduJS8ffuuum50vAsSfNgo KSo5Mo03Eh9tJirlfP1A5aX2vkMrR9cs6zErOkS04e62RxmWP8U1C6GQDv2teVRCPCc4 uavcyYlYblHVa3IxHUhfNnFRV+sbNlNditxhmoaOfSg8cmRAp3hQfWMVxUP1HsxqYk8x PokLPOdmParh464hA95+YjpTzU47vyGYNzBpPiPwZf3HfF6hpTcLH1DD9vrfY2j34LBj 9NZhEXIcpR7W6j4ngX2HHZUaMe63jE860zj4fd0EvST1KCoQgb2MDppdrqPqE/6s8OsK qnfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YHATpWMaMVRwsK53UgPwyPtOK4S9tCP7w+KQf5HKEUE=; b=a8zyv8Fu24EJWeysZIIHE5Pp5/syeskUcBKpNDbfZZpd3qM0gw1mEe9U9479UM2nD9 qd913Ro8ynnaueQB2PACZWVcuBchTWA3xt2IuWNvw8CSVR29IoLbcVD2CPHpwnTPi/1y AXv1BnmeNIuvsPQutsqUrvr4+FMLlEtoRf7s+IZLIyI68aMlHAZlQvplzlhxRfKXYFYa jpWHbZVuiMVpzVsvdTC6HJyldQOoAI7FSZarB7iSCEPP8cMo5l/r74XjFdxyFVkJ9AGS JVcVuI33XdcGoHuQtwYOIPv+qxgr9X//g0JqiPVxaRLx38RI6jMr7IH9+IKNivXGDyNl HyFA== X-Gm-Message-State: AOAM5334QxORE91CYa0C6ZbcwIy2etD6J9CZhn1Iurt0Y489ErCs2Wb8 3ygY+0ns417tbOYKrxP2+PSFoqVQxoBG1/5WRns= X-Google-Smtp-Source: ABdhPJzrGmi4oT3ocvVB02fBynuINBGD8TRokPMnB3qlTKuOYHZ0AL8crqwxG5lSiQuuo9aeu7GQoOodAD7Pt67wZKc= X-Received: by 2002:a54:4701:: with SMTP id k1mr6118921oik.175.1590244891012; Sat, 23 May 2020 07:41:31 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 11:41:19 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: multipart/alternative; boundary="000000000000d5b24c05a651bda8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) --000000000000d5b24c05a651bda8 Content-Type: text/plain; charset="UTF-8" > This is something we have to define. Currently we only complain if one > of the defined functions that was dumped cannot be found in the new > .eln. My preference would be to sign each .eln used for dump to make > sure what we are loading is what we dumped and refuse to load otherwise. What if we find out where the linker has put the shared library, copy that region of memory into the dump file and when loading Emacs we mmap that data into same address it was? It is essentially saving the result of the linker for later use. This would require no ASLR and doing it ASAP to prevent the something from using that address space. Another option: statically link the .eln files (we'd need libgccjit to create static libraries) into the final Emacs executable. This would take care of function definitions and loading the dump would take care of the rest. Nicolas --000000000000d5b24c05a651bda8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=20 This is something we have to define.=C2=A0 Currently we only complain if on= e
> of the defined functions that was dumped cannot be found in the n= ew
> .eln.=C2=A0 My preference would be to sign each .eln used for dump to = make
> sure what we are loading is what we dumped and refuse to load otherwis= e.

What if we find out where the linker has p= ut the shared library, copy that region
of memory into the dump = file and when loading Emacs we mmap that data into
same address i= t was?
It is essentially saving the result of the linker for late= r use. This would require
no ASLR and doing it ASAP to prevent th= e something from using that address space.

Another= option: statically link the .eln files (we'd need libgccjit to create = static libraries)
into the final Emacs executable. This would ta= ke care of function definitions and
loading the dump would take c= are of the rest.

Nicolas
--000000000000d5b24c05a651bda8-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 11:11:08 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 15:11:08 +0000 Received: from localhost ([127.0.0.1]:35302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcVnn-0007Hk-Uw for submit@debbugs.gnu.org; Sat, 23 May 2020 11:11:08 -0400 Received: from mx.sdf.org ([205.166.94.20]:64185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcVnk-0007Ha-9w for 41242@debbugs.gnu.org; Sat, 23 May 2020 11:11:07 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NFB25V001935 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 15:11:03 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NFB29Q029262; Sat, 23 May 2020 15:11:02 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> Date: Sat, 23 May 2020 15:11:02 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 23 May 2020 11:41:19 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> This is something we have to define.=C2=A0 Currently we only complain if > one >> of the defined functions that was dumped cannot be found in the new >> .eln.=C2=A0 My preference would be to sign each .eln used for dump to > make >> sure what we are loading is what we dumped and refuse to load > otherwise. > > What if we find out where the linker has put the shared library, copy > that region > of memory into the dump file and when loading Emacs we mmap that data > into > same address it was? > It is essentially saving the result of the linker for later use. This > would require > no ASLR and doing it ASAP to prevent the something from using that > address space. I don't think would fly: You are not garanteed to be able to obtain the same mmaped address anyway and we cannot go for a solution that does not support ASLR. In general to be portable it cannot rely on assumptions or low level tricks. I think these are (at least part of) the reasons why we moved away from unexec. > Another option: statically link the .eln files (we'd need libgccjit > to create static libraries) > into the final Emacs executable. This would take care of function > definitions and > loading the dump would take care of the rest. Is not that simple, loading eln is mutating the environment with side effects, function definition is just a part of that. Even more important we must support subsequent dumps. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 11:27:15 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 15:27:15 +0000 Received: from localhost ([127.0.0.1]:35324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcW3P-0007gx-Ky for submit@debbugs.gnu.org; Sat, 23 May 2020 11:27:15 -0400 Received: from mail-oi1-f182.google.com ([209.85.167.182]:36520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcW3O-0007gh-Ao for 41242@debbugs.gnu.org; Sat, 23 May 2020 11:27:14 -0400 Received: by mail-oi1-f182.google.com with SMTP id x23so12022601oic.3 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 08:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HM/BZTc1TnVMcJvBx4uRVGitiiKu90iIcwGFQtHE8Y4=; b=beXlm3iCvvLYUG4ypsxFHVaITLOaHN5p84MkeW5yUwdm4RY6ys67ZaVsok30UEC3Y+ FI8PGybJXjqPZIIU04p7PyvJQJDstcZx0ktgs+4vfi0EuOePZRM0xT+3eVi9iGZCE5eV 7cPS7PQ6iI5/vWzApKSt1TuETKOgX2xDf+Ky0M6lnvY5vWBzWFXGOpgAn+dNUmqiYfXC 6zr9g7fisaw/PduxsVar70W1PWrDirrU8O3QNJjGL4TGl25Nanur4009sx2ijlI8jFfD uZw2aPbnm9rkn6tcRC5gsAaAk+en7MSN06Mi8HFhaK4Zw9izSDZd46m8yS0kz3xfRFnF itLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HM/BZTc1TnVMcJvBx4uRVGitiiKu90iIcwGFQtHE8Y4=; b=gObolKe2Ljo+2mmebANC5km5Mfa0oALLLs0Ub5O9WwRgD4AqFO+pj65YSSFJ7+ovQY TJTe5krR495/mayEvMdrrD4wqKL4Pu/MHqScs04g+5qs/CVhUacJMLJmDe66IsQavpNH f54QMiAbimkYpwvUhg/U/sp4wpxz07XBsMqymDUHi7LfKJW6FTUMPCUtZuNe1U1nt+Iw z94toGTMnFQdX8p/Er1G6ajZS4u6O+V0nrAgmWcLm0ZZBIfLTsPvawSVkaIYGzqD2UQa e+yin0u/qYErHvAl8nI4XJs4JaQzN7fkCUE+3dpxbu1Q+Dco1ZaDoIMFavrcTGrzLjjt QCXQ== X-Gm-Message-State: AOAM5312cQkrliwnp4uo+NiK9EbD+2Z9HdT3huaZvEhKifyzC4H+fpv4 +WNNkCn9UQj+7wdtTO04pi4Lb3bRjcNzucXqgPA= X-Google-Smtp-Source: ABdhPJwjE2VxyE8w86zGRBR3f9Oma1Sv4M8wgSok+08D8uLd5X2nM1u0Tu6pcyySPT2qu/nKd33JmDizLNqXZgqL3Jg= X-Received: by 2002:aca:ac0e:: with SMTP id v14mr6158476oie.65.1590247628499; Sat, 23 May 2020 08:27:08 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 12:26:56 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Andrea Corallo Content-Type: multipart/alternative; boundary="000000000000006fff05a6526138" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) --000000000000006fff05a6526138 Content-Type: text/plain; charset="UTF-8" > I don't think would fly: You are not garanteed to be able to obtain the > same mmaped address anyway and we cannot go for a solution that does not > support ASLR. In general to be portable it cannot rely on assumptions > or low level tricks. I think these are (at least part of) the reasons > why we moved away from unexec. AFAIU ASLR is disabled already, at least in Windows. > Is not that simple, loading eln is mutating the environment with side > effects, function definition is just a part of that. I know, but linking against a static .eln would just make the symbols available, not anything else. The mutation of the environment would happen when loading the dump. > Even more important we must support subsequent dumps. You are right. I hadn't considered this. Nicolas --000000000000006fff05a6526138 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I don't think would fly: You are not garanteed to be able to obtai= n the
> same mmaped address anyway and we cannot go for a solution that does n= ot
> support ASLR.=C2=A0 In general to be portable it cannot rely on assump= tions
> or low level tricks.=C2=A0 I think these are (at least part of) the re= asons
> why we moved away from unexec.

AFAIU ASLR is disabled al= ready, at least in Windows.
> Is not that simple, loading eln is mutating the environment with side<= br> > effects, function definition is just a part of that.

I know, but linking against a static .eln would just make the symbols avail= able,
not anything else. The mutation of the environment would ha= ppen when loading
the dump.

> Eve= n more important we must support subsequent dumps.<= br>

You are right. I hadn't considered this.

Nicolas
--000000000000006fff05a6526138-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 11:52:11 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 15:52:11 +0000 Received: from localhost ([127.0.0.1]:35350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWRR-0008IM-Og for submit@debbugs.gnu.org; Sat, 23 May 2020 11:52:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWRQ-0008Hs-Mw for 41242@debbugs.gnu.org; Sat, 23 May 2020 11:52:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44592) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcWRL-0007f6-Cj; Sat, 23 May 2020 11:51:59 -0400 Received: from [176.228.60.248] (port=4538 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcWRJ-0008GO-M6; Sat, 23 May 2020 11:51:59 -0400 Date: Sat, 23 May 2020 18:52:04 +0300 Message-Id: <83imgmzm1n.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 11:41:19 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 11:41:19 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > Another option: statically link the .eln files (we'd need libgccjit to create static libraries) > into the final Emacs executable. This would take care of function definitions and > loading the dump would take care of the rest. That would preclude re-dumping Emacs, no? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 12:00:58 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 16:00:58 +0000 Received: from localhost ([127.0.0.1]:35383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWa1-00006D-O6 for submit@debbugs.gnu.org; Sat, 23 May 2020 12:00:57 -0400 Received: from mx.sdf.org ([205.166.94.20]:53987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWZy-000063-53 for 41242@debbugs.gnu.org; Sat, 23 May 2020 12:00:56 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NG0qd3028094 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 16:00:52 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NG0qA2023508; Sat, 23 May 2020 16:00:52 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> Date: Sat, 23 May 2020 16:00:52 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 23 May 2020 12:26:56 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> I don't think would fly: You are not garanteed to be able to obtain > the >> same mmaped address anyway and we cannot go for a solution that > does not >> support ASLR.=C2=A0 In general to be portable it cannot rely on > assumptions >> or low level tricks.=C2=A0 I think these are (at least part of) the > reasons >> why we moved away from unexec. > > AFAIU ASLR is disabled already, at least in Windows. The fact that is now disabled does not imply that we want to prevent us from using it for the future, that said AFAIU given the personality of my running Emacs is zeroed (i'm on GNU/Linux) it is running with ASLR enabled. See also 'maybe_disable_address_randomization'. >> Is not that simple, loading eln is mutating the environment with > side >> effects, function definition is just a part of that. > > I know, but linking against a static .eln would just make the symbols > available, > not anything else. The mutation of the environment would happen when > loading > the dump. Is more complex because we can have in the eln code that at top level relies on functions as: (defun foo () ..) (some code that depends on the definition of foo) (defun foo () ..) So function definition and other top level executon is mixed. I think this could be worked around but is tricky. >> Even more important we must support subsequent dumps. > > You are right. I hadn't considered this. Yeah I think this the real no go. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 12:03:34 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 16:03:34 +0000 Received: from localhost ([127.0.0.1]:35387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWcY-0000A9-4v for submit@debbugs.gnu.org; Sat, 23 May 2020 12:03:34 -0400 Received: from mail-oi1-f174.google.com ([209.85.167.174]:39700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWcW-00009x-ID for 41242@debbugs.gnu.org; Sat, 23 May 2020 12:03:32 -0400 Received: by mail-oi1-f174.google.com with SMTP id s198so12068658oie.6 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 09:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=02Xc2CA9QYPv8+4Nlq7+/BG7fvSw387pd7tugr/rm6w=; b=i1PtlF8iKvGnZTcssEPYOQkOHBPseESm7AnRnRLQ8tDDXQN9RrvALKPAOYs4HxTieR Anejmri+8UvU6BEnZ+KZ7+mkignbz6QrFfeZxMGPfl1FYc85Xg0jlo0cR9w0rVNDXPb8 L3K5VlGps1gBEzCNHDTzL0eOtEsOMfrWMJ4XZeWX56jRI/cPNeZh95LAQd4cLffaHUFT OfqxXJ22yDsp3FLJQgZBeja2a2ZSRtLayANsOg0mZpX2dMI1ZA3GmDxn5iQKIHxsPBbw BHtvfGn9XDpV3AsMHL2gprJiGNZgnroi6bn/wm52f0q23HDcUxG4OQm64a8DnQ06LODD VvzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=02Xc2CA9QYPv8+4Nlq7+/BG7fvSw387pd7tugr/rm6w=; b=Iqy2cldpq0wU288KivYTHaZ0QuFceGRf06w7vA6LlIGHEShuWNELGbG/AUOEBrWIO2 VP1FhmT/RbsI7+0HCqffKQbZAT2K6A+rQa55/wne2NnIH/gYuq/RgGrHzsKy6cHn00Dz dGuuxfrQfXmuVJeMZHvxoSQ9w0z5pEnHWZXT6cQgq8UfXL+1s8DSdfFLh/rCBCZUFfw7 +J+8cEXi2hXpeR8ZAzjm9I5xnJLPpjX6ybinNMi5a8RUpCKj5Eiq2RwvOAn2nCxEh/OS Bh4dUahPgbfG+BNuvdpIX10jUhV2Wfwur/UpiM3e9Yt2Xp7nV5a0yeEhuI8K2mBzMVF9 lTkw== X-Gm-Message-State: AOAM531IKWrDVe2tzDaK+A9J7NTEcNrJH9X4jXugJyvDGpdoCNt/YPYs vpQhrW1mlteKZj/97zjz98eGR3RB+BgTpqzYvAw= X-Google-Smtp-Source: ABdhPJyDUX1fFlSaPXm1QNrfbFN0EDfYkGt309OnA3t62nFpOigFYgiSG/1WdSHdvag7fn/P7z1j+VgrgucMDRj8z0s= X-Received: by 2002:a54:4701:: with SMTP id k1mr6350869oik.175.1590249806779; Sat, 23 May 2020 09:03:26 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83imgmzm1n.fsf@gnu.org> In-Reply-To: <83imgmzm1n.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 13:03:14 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d6580705a652e231" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --000000000000d6580705a652e231 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > That would preclude re-dumping Emacs, no? I guess so. I didn't think about that option. As Andrea said, this is a no go. El s=C3=A1b., 23 may. 2020 a las 12:52, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 23 May 2020 11:41:19 -0300 > > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > > > Another option: statically link the .eln files (we'd need libgccjit to > create static libraries) > > into the final Emacs executable. This would take care of function > definitions and > > loading the dump would take care of the rest. > > That would preclude re-dumping Emacs, no? > --000000000000d6580705a652e231 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> That would preclude re-dumping Emacs, no?

I guess so. I didn't think about that option.
As Andrea sai= d, this is a no go.


El s=C3=A1b., 23 may. 2020 a la= s 12:52, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
> From: Nicolas B=C3=A9rtolo <nicolasbertolo@gmail.com= >
> Date: Sat, 23 May 2020 11:41:19 -0300
> Cc: Eli Zaretskii <eliz@gnu.org>, 41242@debbugs.gnu.org
>
> Another option: statically link the .eln files (we'd need libgccji= t to create static libraries)
> into the final Emacs executable. This would take care of function defi= nitions and
> loading the dump would take care of the rest.

That would preclude re-dumping Emacs, no?
--000000000000d6580705a652e231-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 12:04:32 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 16:04:32 +0000 Received: from localhost ([127.0.0.1]:35398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWdU-0000CL-0o for submit@debbugs.gnu.org; Sat, 23 May 2020 12:04:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWdS-0000C9-SC for 41242@debbugs.gnu.org; Sat, 23 May 2020 12:04:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44824) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcWdN-0001fk-Cg; Sat, 23 May 2020 12:04:25 -0400 Received: from [176.228.60.248] (port=1373 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcWdL-0001Nu-TD; Sat, 23 May 2020 12:04:24 -0400 Date: Sat, 23 May 2020 19:04:31 +0300 Message-Id: <83eerazlgw.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 12:26:56 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 12:26:56 -0300 > Cc: Eli Zaretskii , 41242@debbugs.gnu.org > > AFAIU ASLR is disabled already, at least in Windows. I don't think so, I see it on modern versions of Windows all the time. From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 12:20:28 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 16:20:28 +0000 Received: from localhost ([127.0.0.1]:35427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWsu-0002hY-Ke for submit@debbugs.gnu.org; Sat, 23 May 2020 12:20:28 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:39469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcWst-0002hK-34 for 41242@debbugs.gnu.org; Sat, 23 May 2020 12:20:27 -0400 Received: by mail-ot1-f54.google.com with SMTP id d7so10680863ote.6 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 09:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dcW1ubwKx1ocJXmriuK72W6X6NjAGeOAFMXYT+SRrK0=; b=EI2aV093KarX/jNAGtDkGf6+SnGcsqEWivSzGQ7SHNIJmwwk9sIuH8GlVu1iYbX13Y vZqBDpytSexHbIgvp7egFnZvgKxGEqVKrh8h/U5sYO1cGVbK9CsHyit6H3GET2vb3jzl o+PBf0Ia4NMBeK+tv4V2FCcrldB4/ENRK2y/2IUiYim5h9ILlS14DzPm0IfjOqUMbGMD JoJh7aiwRD7aSYUj5NKelruIlM2EWsZwctBYMbwjz3iLaSyONSyk9ubQfpk+xgLiibKl uIfFUT5YB8cIhhrRk1d72COP5gl2umaeTUTf5ieLkakxxnaA5qmiJUJILfQSOKAVxyfL rI1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dcW1ubwKx1ocJXmriuK72W6X6NjAGeOAFMXYT+SRrK0=; b=WsJ1dssAQ0IimYO2R9zm1YH+rzH8z9rdzb2Mc/wiQv/DZup2Jn/dAf9jzPyobXtlbI +dtT1kZOssLWARCKAQiZORUdL8Cy7ji1lr34nOE3ItOPVpnxAzavYBohFapuHkC3jox7 glcQF9a0EngHoAFFx7E7csEWHny+9XQ+xPffjCoWUAytPDAPr57/m1OI29niPWQzPmgo tMcOQxky0cIrDp4dQqN5E5ohBHJrmr0xVM+O3jWgKs6FcjSrp4IzlwZugmgVLs2+Kd7A qY7ZBmq2pbK/C9cGZ8lPBqNx1wAvw2Y6mzO9YS71DEC7VJ+FiKWfSi495pRZKhoIADhx bbsw== X-Gm-Message-State: AOAM532mEIDZIBGmj/GLju098hylRgBAJaYiUM6PRCD9MhZHtozkbxpj LWL+jGfzQp0x+JFXe5hVB+jr/Zk2/vGwpHgDhE0E2iuLr5OBgQ== X-Google-Smtp-Source: ABdhPJxBuEWPJJzNtruirBVuiRBTVmCpxRmrScwq/74MMQkxxfZyTg6Udqg1VSLzRZHLCLaay34LWlq/bzDUgD+xm/k= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr15140016oti.202.1590250821414; Sat, 23 May 2020 09:20:21 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> In-Reply-To: <83eerazlgw.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 13:20:06 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000050722605a6531f29" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --00000000000050722605a6531f29 Content-Type: text/plain; charset="UTF-8" > I don't think so, I see it on modern versions of Windows all the time. Using ProcessExplorer this is what I see in my machine: - emacs.exe is always loaded @ 0x40000000. - .eln files do not have the ASLR flag enabled and "Image Base" == "Base". Nicolas --00000000000050722605a6531f29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I don't think so, I see it on modern version= s of Windows all the time.

Using ProcessExplo= rer this is what I see in my machine:

- emacs.exe = is always loaded @ 0x40000000.
- .eln files do not have the ASLR = flag enabled and "Image Base" =3D=3D "Base".
=
Nicolas
--00000000000050722605a6531f29-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 13:04:58 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:04:58 +0000 Received: from localhost ([127.0.0.1]:35449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcXZy-0005s5-6R for submit@debbugs.gnu.org; Sat, 23 May 2020 13:04:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcXZw-0005rr-I0 for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:04:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46140) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcXZq-0004US-3L; Sat, 23 May 2020 13:04:50 -0400 Received: from [176.228.60.248] (port=1198 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcXZp-0002KO-8u; Sat, 23 May 2020 13:04:49 -0400 Date: Sat, 23 May 2020 20:04:56 +0300 Message-Id: <83367qzio7.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 13:20:06 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 13:20:06 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > I don't think so, I see it on modern versions of Windows all the time. > > Using ProcessExplorer this is what I see in my machine: > > - emacs.exe is always loaded @ 0x40000000. > - .eln files do not have the ASLR flag enabled and "Image Base" == "Base". My observation was based on the fact that addresses of the same objects that I see in the debugger are different from session to session on Windows 7 and Windows 10, but not on XP. From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 13:20:29 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:20:29 +0000 Received: from localhost ([127.0.0.1]:35454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcXoz-0006FU-JV for submit@debbugs.gnu.org; Sat, 23 May 2020 13:20:29 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:35781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcXoy-0006FC-5m for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:20:28 -0400 Received: by mail-ot1-f48.google.com with SMTP id 69so10808206otv.2 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 10:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IKIkJU1WmXEEKzNnWC7OzYUE+jXPNK4Nt1rddmUlsGg=; b=dPxRr1Ypi11tyckC/DezjARTPPzoU3tuqwOD8r0gpNMhexJBQzwTnqqzEylzHzFR0j 4bKb+JXztSFFc2vtI6MV2WbYllmqcU0dBN7Ch0rdO4mTInOjDAIQGyxRIrjNQ3SMENSJ +3x5JJxgLcTl05tzR8CU0ngb55D7zA8m9l9/gKWOACH0geGFgXOf/XS6SYh5hTcecKfZ vIptHsynQIEha/iasHGz9OJ9vd6ph2o4y5uiPAuxcmgIBLLOokfW5Cn8N5EJrhqK/XSw Ka5bf7LqvTRfjafFComLn6Xcx2wA+oGSQwygq8H3Vbulg9ZnmBq96zAhNJ/zGvwyZtGb CUKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IKIkJU1WmXEEKzNnWC7OzYUE+jXPNK4Nt1rddmUlsGg=; b=mFWj/R0NihD+uPYKUFttFaqKpkvpRw5fjQxSikDE35S6XLHW4Kzg4DzJnOFGtltbaU HthywCHQIKr0c3QJhofKheiA2exBVVwopr4KcXrGVhd8aIDq9DFG/usveIKLhlaqqd6F Nw5zKVIsdTSWjQNjmO8g7OOPUfah0QCPy134Cxs5TesjRj6phprH6fOd/JN4CFW4L1/w Rq3iYwnlhV3wp4u+pFzRUJ2hMcs7qwHW0dZFJ6v0iM43S4g9W2gp5yOIuHYQq3oM37SB sQMWjYovKBVYHQBXSfqyIObflm/4//KvezaoOFgiX6FJUP6tE07IgkfcVrCSa8ebm8XV QDvg== X-Gm-Message-State: AOAM531J4gsAIr2V5dmpahSBL1hIX7UrwnDPMofTiAgzLfJf/jZ29FaI bZABvR+Ev2mceN/fDtyM6oFcc9GoIazg/VKcJuc= X-Google-Smtp-Source: ABdhPJzZsFmsvBlxo80gIGj4se536afKS23nMp/IYNEPfEjrlKbVZJ6crF/wUOq+wg+mTXhQO9198i6vUnk3rtgvqfY= X-Received: by 2002:a9d:12f4:: with SMTP id g107mr9994448otg.352.1590254422431; Sat, 23 May 2020 10:20:22 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> In-Reply-To: <83367qzio7.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 14:20:09 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f39c1205a653f5bd" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --000000000000f39c1205a653f5bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > My observation was based on the fact that addresses of the same > objects that I see in the debugger are different from session to > session on Windows 7 and Windows 10, but not on XP. That would mean that the heap is randomized, right? But the code could still be always loaded at the same address. Coming back to the performance problem when loading: apart from reducing the number of files probed, we could try parallelizing openp() using a thread pool. What do you think? Nicolas El s=C3=A1b., 23 may. 2020 a las 14:04, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 23 May 2020 13:20:06 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > I don't think so, I see it on modern versions of Windows all the time= . > > > > Using ProcessExplorer this is what I see in my machine: > > > > - emacs.exe is always loaded @ 0x40000000. > > - .eln files do not have the ASLR flag enabled and "Image Base" =3D=3D > "Base". > > My observation was based on the fact that addresses of the same > objects that I see in the debugger are different from session to > session on Windows 7 and Windows 10, but not on XP. > --000000000000f39c1205a653f5bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=20 My observation was based on the fact that addresses of the same
> obj= ects that I see in the debugger are different from session to
> session on Windows 7 and Windows 10, but not on XP.
That would mean that the heap is randomized, right? But the cod= e could
still be always loaded at the same address.

Coming back to the performance problem when loading: apart= from reducing
the number of files probed, we could try parallel= izing openp() using a thread
pool. What do you think?
<= br>
Nicolas

El s=C3=A1b., 23 may. 2020 a las 14:04, Eli = Zaretskii (<eliz@gnu.org>) escrib= i=C3=B3:
> Fr= om: Nicolas B=C3=A9rtolo <nicolasbertolo@gmail.com>
> Date: Sat, 23 May 2020 13:20:06 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > I don't think so, I see it on modern versions of Windows all = the time.
>
> Using ProcessExplorer this is what I see in my machine:
>
> - emacs.exe is always loaded @ 0x40000000.
> - .eln files do not have the ASLR flag enabled and "Image Base&qu= ot; =3D=3D "Base".

My observation was based on the fact that addresses of the same
objects that I see in the debugger are different from session to
session on Windows 7 and Windows 10, but not on XP.
--000000000000f39c1205a653f5bd-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 13:35:45 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:35:45 +0000 Received: from localhost ([127.0.0.1]:35459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcY3k-0006bc-W5 for submit@debbugs.gnu.org; Sat, 23 May 2020 13:35:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcY3i-0006bP-Kn for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:35:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46655) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcY3d-0000a0-AI; Sat, 23 May 2020 13:35:37 -0400 Received: from [176.228.60.248] (port=3087 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcY3c-0004nf-OG; Sat, 23 May 2020 13:35:37 -0400 Date: Sat, 23 May 2020 20:35:44 +0300 Message-Id: <83zh9yy2of.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 14:20:09 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 14:20:09 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > My observation was based on the fact that addresses of the same > > objects that I see in the debugger are different from session to > > session on Windows 7 and Windows 10, but not on XP. > > That would mean that the heap is randomized, right? But the code could > still be always loaded at the same address. I don't remember if it was only the heap, or also addresses of other areas. For example, I think the stack was also in a different area. > Coming back to the performance problem when loading: apart from reducing > the number of files probed, we could try parallelizing openp() using a thread > pool. What do you think? I'd start by reducing the number of probed files, and then I'd benchmark the results and see if it's "good enough". Threads add another dimension of complexity, so I'd only go there if we have a very good reason. From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 13:47:24 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:47:24 +0000 Received: from localhost ([127.0.0.1]:35474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYF2-0006sR-H7 for submit@debbugs.gnu.org; Sat, 23 May 2020 13:47:24 -0400 Received: from mail-ot1-f53.google.com ([209.85.210.53]:33252) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYF0-0006sD-PO for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:47:23 -0400 Received: by mail-ot1-f53.google.com with SMTP id v17so10879474ote.0 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 10:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dPyxg+s3Ps3KiNhboXrvMx2r/9DDvGud7SvW2azWj+I=; b=cJQApMFFjOqKQAKDzyoBFvzs7MDtQF3zL+l/m8R0KDArNPvsd/PaRAa0jN0SShcQW1 fBqUyJIYp+2R2LYp6s0DFfe3bbUJkYjPoQ58b5DJsOGuSA9OyVp4GKdNi9xgh/Ank7ak vVGhce1ANTOL3edXlj8yJauRhs6o8W+FI8fUSdtL+NEj9XjkuojYHjPiy9+E9rYNnAJX Jra9pgu+MrPVmzoNLFfhNdsVy87et7yK+z48aY2WsI4r/FmMFyO8mCK82Sc4XtTmpqvi gHx3/lzZ8R/RBVGEtS3G3sYEPGYnym1HPykgS7nKgXFQ1/eWNEaMaRLVcyMVsD5FQnKU UV0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dPyxg+s3Ps3KiNhboXrvMx2r/9DDvGud7SvW2azWj+I=; b=sUgCu1FoQ/0NwvFMyJs3HPeLtLG8wGN5AJX7Mp3b10f9eNgZDRGTuTAES3xMXmbsFp 1eC7wwQLMjaGlv+fFW9DZJpwOEQ+AbgoygYXzN8aGOYRWxoQ5Zs9NRbwIVdccjL8zjqu uMoS6KgylpsIaeo1AFl7cEkrR5YSX7FIzwJWIWdLmhgC5GpJ67OKaLW24wePOlxzFxYF lVYaqt3cOn8gxcmsTcCG5vLYJiWEWfE4yuuVLuyfTGflDmLxyzRAFuPfv2qzn0tsA8Z0 WrsBGL3gaRJkh8HUXBLBQ20DVePKgDD+Gf6UgH0eXEtp6HxyJnPNEitcAaa73dX0gzIl cXow== X-Gm-Message-State: AOAM53202EkRKB7PsXYV3asKemYa1RfthIwi15Hs8+WjXKUUAT+l1QjL SCIkUFpkPBDQm9QGLT6oguKfyDdnyO8rqT+nJeQ= X-Google-Smtp-Source: ABdhPJxAAjw7QOsfaVP97/zVRaKwxJ3vJY093OZ2fHJG7PM3epF6hgzaDWq56R6n0N587vq/w+cXOxTZlnoNZF8BlBM= X-Received: by 2002:a9d:191:: with SMTP id e17mr14723699ote.193.1590256037029; Sat, 23 May 2020 10:47:17 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> In-Reply-To: <83zh9yy2of.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 14:47:03 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000306a2005a654567f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --000000000000306a2005a654567f Content-Type: text/plain; charset="UTF-8" > I'd start by reducing the number of probed files, and then I'd > benchmark the results and see if it's "good enough". Threads add > another dimension of complexity, so I'd only go there if we have a > very good reason. Just to show some numbers: I run a fairly heavy Spacemacs configuration. Without any patch it takes 80 seconds to start. Reducing the number of probed files takes this down to 40 seconds. The VTune profiler tells me it is spending 80% of the time waiting for openp(). I'll rewrite the patch to reduce the number of probed files. --000000000000306a2005a654567f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'd start by reducing the number of probed files, and then I'd=
> benchmark the results and see if it's "good enough".=C2= =A0 Threads add
> another dimension of complexity, so I'd only go there if we have a=
> very good reason.

Just to show some numbers:<= /div>
I run a fairly heavy Spacemacs configuration.
Without = any patch it takes 80 seconds to start.
Reducing the number of pr= obed files takes this down to 40 seconds.

The VTun= e profiler tells me it is spending 80% of the time waiting for openp().

I'll rewrite the patch to reduce the number of pr= obed files.
--000000000000306a2005a654567f-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 13:56:07 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 17:56:08 +0000 Received: from localhost ([127.0.0.1]:35483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYNT-00075B-LS for submit@debbugs.gnu.org; Sat, 23 May 2020 13:56:07 -0400 Received: from mx.sdf.org ([205.166.94.20]:51760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYNQ-00074y-0v for 41242@debbugs.gnu.org; Sat, 23 May 2020 13:56:06 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NHu2TM005511 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 17:56:02 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NHu25k023496; Sat, 23 May 2020 17:56:02 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> Date: Sat, 23 May 2020 17:56:02 +0000 In-Reply-To: <83zh9yy2of.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 May 2020 20:35:44 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , 41242@debbugs.gnu.org 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: >> Coming back to the performance problem when loading: apart from reducing >> the number of files probed, we could try parallelizing openp() using a thread >> pool. What do you think? > > I'd start by reducing the number of probed files, and then I'd > benchmark the results and see if it's "good enough". Threads add > another dimension of complexity, so I'd only go there if we have a > very good reason. Agree, also I think before that would be necessary to prove that parallelizing in user space let the kernel scale up in performance in serving the syscalls. I'm not really sure about that and the observed bottle neck is apparently there. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 14:21:43 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 18:21:43 +0000 Received: from localhost ([127.0.0.1]:35537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYmF-0007iH-2r for submit@debbugs.gnu.org; Sat, 23 May 2020 14:21:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYmD-0007i6-Oj for 41242@debbugs.gnu.org; Sat, 23 May 2020 14:21:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47314) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcYm8-00086r-3A; Sat, 23 May 2020 14:21:36 -0400 Received: from [176.228.60.248] (port=1930 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcYm6-0001WU-I4; Sat, 23 May 2020 14:21:35 -0400 Date: Sat, 23 May 2020 21:21:42 +0300 Message-Id: <83y2piy0jt.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 14:47:03 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 14:47:03 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > Just to show some numbers: > I run a fairly heavy Spacemacs configuration. > Without any patch it takes 80 seconds to start. > Reducing the number of probed files takes this down to 40 seconds. > > The VTune profiler tells me it is spending 80% of the time waiting for openp(). If it takes us 32 seconds to run openp, then how many files do we try to probe? 32 sec is eternity! From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 14:29:44 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 18:29:44 +0000 Received: from localhost ([127.0.0.1]:35546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYu0-0007tL-3P for submit@debbugs.gnu.org; Sat, 23 May 2020 14:29:44 -0400 Received: from mail-oi1-f173.google.com ([209.85.167.173]:34055) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcYty-0007t9-V5 for 41242@debbugs.gnu.org; Sat, 23 May 2020 14:29:43 -0400 Received: by mail-oi1-f173.google.com with SMTP id w4so12341131oia.1 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 11:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l5lBgriqDqvmVxV/n1nD84OX3k15ztH85h/3vdYZXno=; b=B294XP6aiS5AvXWKpeZMiAO7tlbkWdJsDK2FJEiEIwalx8dzMRE5kz5V0jh6SoW0xX BH11T0rfWHo7HlPWd2rh5dIx2Vmw4qqIM/fnEYvuRVkq7baL9YQafJJpVrjHq8mz3Ogr OUr1TiJPTOO27+c3YdYJcScFNHLs3OPJ3MHc3hNxVc4446a1MwydM3+TSdfuJ70hCl3Z Xir6yaecLgrwAYa+d6CK77QR3K885yOkFcn1y7I8wk4e42TgNGsuhy4TySJ7HESUHzf1 6nB1CYBiKnjpT4PH3EgRsvMhgKUoMrvE5kmHJplhOPjy7GzK93bPVpof2Go9vHX+FmXK nLOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l5lBgriqDqvmVxV/n1nD84OX3k15ztH85h/3vdYZXno=; b=QY5OVnFwQA1cEtNU1/0Mxln2h7HUqyJcxh8gp8nbMWBbxsKQXea4dVSwutoPdM1vHN f9ZwqOu8VUxQt751FLZShkBqfRKDnUP0UZOJQOOoeuG0RFvQ1vsOKrKNi5wpb97NDfjg zij1kmzPuDOId1l/RxY5AI6A1NtiqWuzDAIg+NP2hnKswbqrD4ACoLrrZG9TsdR2ijh0 acFXQ0QGb6qR7SiHEVk8TmjkBhgIY1fYgEFtJprsdzNeNn9TK2+gSxHX1sOOguW7VqMA t9rvt0zNZa0fFj6DTOZiv2ptr2hrNUs4bQ1NuGQLgUo61UlmNUk5A3Lvk+xkJ0OTY+Za P+bw== X-Gm-Message-State: AOAM5314Q+O11rXKJ0EiUgiuMVjpxQ0NBbGuVKPQK9Ji6FdI0LVwGmQ4 bHT55va6RsINtIHySvJohL80O93KBn+nb+6R+lc= X-Google-Smtp-Source: ABdhPJz6yrFJIpwO7hff63KyNWqGX79nOhddndLdjDnQSpjSSrloc/4min52Fsz2xrMZtTjnacX8lgGq3ZuPhWFgL2E= X-Received: by 2002:aca:e104:: with SMTP id y4mr6220027oig.120.1590258577109; Sat, 23 May 2020 11:29:37 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> In-Reply-To: <83y2piy0jt.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 15:29:25 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000009705d905a654ed43" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --0000000000009705d905a654ed43 Content-Type: text/plain; charset="UTF-8" > If it takes us 32 seconds to run openp, then how many files do we try > to probe? 32 sec is eternity! `load-path' has 380 entries, and load-prefer-newer is true. That is why it is so slow. Loading foo.el from package foo requires probing 6 different extensions (.eln, .dll, .elc.gz, .elc, .el, .el.gz) in 380 directories. 6*380 = 2280 calls to wopen() per call to `load` or `require` --0000000000009705d905a654ed43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> If it takes us 32 seconds to run openp, then how many files do we try<= br>
> to probe?=C2=A0 32 sec is eternity!

`load-path' has 380 entries, and load-prefer-= newer is true. That is why it is so slow.
Loading foo.el from pac= kage foo requires probing 6 different extensions
(.eln, .dll, .e= lc.gz, .elc, .el, .el.gz) in 380 directories.
6*380 =3D 2280 call= s to wopen() per call to `load` or `require`
--0000000000009705d905a654ed43-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 14:37:21 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 18:37:21 +0000 Received: from localhost ([127.0.0.1]:35556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcZ1N-00085Z-CX for submit@debbugs.gnu.org; Sat, 23 May 2020 14:37:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcZ1M-00085O-B0 for 41242@debbugs.gnu.org; Sat, 23 May 2020 14:37:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47514) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcZ1F-0002kh-Re; Sat, 23 May 2020 14:37:13 -0400 Received: from [176.228.60.248] (port=2894 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jcZ1F-0004dL-6N; Sat, 23 May 2020 14:37:13 -0400 Date: Sat, 23 May 2020 21:37:20 +0300 Message-Id: <83sgfqxztr.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 23 May 2020 15:29:25 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 23 May 2020 15:29:25 -0300 > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > If it takes us 32 seconds to run openp, then how many files do we try > > to probe? 32 sec is eternity! > > `load-path' has 380 entries Is this due to Spacemacs setup, or something else? Why would you have so many directories in your load-path? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 14:43:58 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 18:43:58 +0000 Received: from localhost ([127.0.0.1]:35609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcZ7m-0008IN-3H for submit@debbugs.gnu.org; Sat, 23 May 2020 14:43:58 -0400 Received: from mail-oi1-f181.google.com ([209.85.167.181]:42661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcZ7k-0008IB-KV for 41242@debbugs.gnu.org; Sat, 23 May 2020 14:43:56 -0400 Received: by mail-oi1-f181.google.com with SMTP id l6so12317204oic.9 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 11:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Ol+rsxvbtGH7zeGMhPIUiLPGYhP931IKxn3UURlfOg=; b=GMtScWDGxNp1hoJKlXAHxHiNe5n/VcSHk5Dhzozy0B9qndGIU+st95YG+/2h9yCO7k LQk28H8shv7u2gE5YvFXdwx0wVeJOCorhkL/ZPSX6t9ifpaZF5Gf6nnMrk5mBGjgjz6O EMQs7+RhGxT/Rf1ofQ0aAZvz1GobfeIVUCjv+Vm0rW8A4gcpsgRWfCHvfvicQbebRZ8e /wS9si4R1SwNBFGYrpzAA3d/OwlWhnCjPrdg7dpuONh83zCxEeYJ7PU2Z905wv0vRjNY fp3083Ht3tCPorPQLoNe51iLwqh0Pcbz60XPtqh2obTpCq6qYbh+oioeirwfGl4nx9AQ xdHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Ol+rsxvbtGH7zeGMhPIUiLPGYhP931IKxn3UURlfOg=; b=ZO6eThJMarczje9NrUFqhTGgDKb1DVxnJ2+eHjrG4HVhuHkNjAEP2gs6Qp9P49T4nJ lOFXiake+0uJGhP8h5Y55PAGma+oGlMMS0YT1cHmb/AOfVSpwMBalZIaJaamXCrZr74G /sTJIyD0lj7azhNh59iXsDoqKc2VKiQ2KEt1EdHCJtWu3HyeIqk8WA+RdkTclmzdDMvV lxv8myv/iUX+ppdgZ8a4R9sBvgScUtVR49CG/Mn1NxqilerFsX3JPwY8VcMjkRlKv1gm kq8/YXjrjFTE9aaQ3AT1wnPgMS7iJMbl6uFJf4YQ1+mvlrltxh03zI26NdNyWNIPF7+k oeaA== X-Gm-Message-State: AOAM531KOdoH2gMOlz4V3LjtGR3KRSqkjfnCrl8S7qHCWbCnKBAI4giT Dv1PiAbY60CZFI7wxq8b6CpVKOFH4BGLIHqMI60= X-Google-Smtp-Source: ABdhPJzN8yYYJtxyaCT5leh6V2B3NuGwd/L7AyhAueXaDGgLHEALeRsSXaKTgFI32seoLEVlvwI/oeIxgXOLzOb+UbA= X-Received: by 2002:aca:ac0e:: with SMTP id v14mr6634743oie.65.1590259431013; Sat, 23 May 2020 11:43:51 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> <83sgfqxztr.fsf@gnu.org> In-Reply-To: <83sgfqxztr.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 15:43:39 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000007c825f05a6552061" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --0000000000007c825f05a6552061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Why would you have so many directories in your load-path? Because I have many Spacemacs layers installed, each installs many packages and each package has its own directory in `package-user-dir`. El s=C3=A1b., 23 may. 2020 a las 15:37, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 23 May 2020 15:29:25 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > If it takes us 32 seconds to run openp, then how many files do we try > > > to probe? 32 sec is eternity! > > > > `load-path' has 380 entries > > Is this due to Spacemacs setup, or something else? Why would you have > so many directories in your load-path? > --0000000000007c825f05a6552061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=20 Why would you have so many directories in your load-path?

Becaus= e I have many Spacemacs layers installed, each installs many packages
=
and each package has its own directory in `package-user-dir`.

El s=C3=A1b., 23 may. 2020 a las 15:37, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
> From: Nicolas B=C3=A9rtolo <<= a href=3D"mailto:nicolasbertolo@gmail.com" target=3D"_blank">nicolasbertolo= @gmail.com>
> Date: Sat, 23 May 2020 15:29:25 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > If it takes us 32 seconds to run openp, then how many files do we= try
> > to probe?=C2=A0 32 sec is eternity!
>
> `load-path' has 380 entries

Is this due to Spacemacs setup, or something else?=C2=A0 Why would you have=
so many directories in your load-path?
--0000000000007c825f05a6552061-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 18:52:34 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 22:52:34 +0000 Received: from localhost ([127.0.0.1]:35993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd0M-000829-Fk for submit@debbugs.gnu.org; Sat, 23 May 2020 18:52:34 -0400 Received: from mail-ot1-f43.google.com ([209.85.210.43]:45234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd0L-00081w-20 for 41242@debbugs.gnu.org; Sat, 23 May 2020 18:52:33 -0400 Received: by mail-ot1-f43.google.com with SMTP id c3so11127530otr.12 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 15:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vIiPZd3l8BiOAU1GK/KqYmrqoAu6Sb378l6S+3tO+os=; b=K8UmnMUOJSJtrJjl5e6aFxhW8gXB1kOh5FyMLm/wEQPwE1bAV3qgfsIUNiDDVB2Exa GShMYUB2xgC50Pds7OiGIJXYTz4fQFYHr5NnN93DxLZ/kwnAXuTsAzmpmOGDsP0jwmgI 3fH63LPJ+/CCCya7aAouJcoqIcLU09sl6ebj9g0MlzrZl8A9WZPKhFVdwcjDr/0Nl5Qz BtfGfYHv3PXGA4evNv3RmILALmbhKtW5fFNLGlQWbnkaV3XcmkSdnMBVNgqc/xs9/DZJ Hxkx7B2QjJSfNe8e9K8AZAyV+GXpWNDjUdVuT9xLtVOxAOMuhFo85tLpeQ+Cot2C38HA w7Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vIiPZd3l8BiOAU1GK/KqYmrqoAu6Sb378l6S+3tO+os=; b=B6VEmjEs20tS1O4rSEqmQX47/uQoXkcohHgK7H391bSGZoLk8SZe8guqgPAfrwNxvW PLseartDycKj20yWynA8KGmHVHjSdMFYeMRYGU/LYgYvVH+gnQTcByfikFkoRTni6+w6 1iUFFfQOsZEGL+BlxjtylQW7byNDJ9UoC4EfmVcf/u3zU3RPP9ARDdMCRBUNxS/lUfvA IWRJTm+p9ayHoqcQ82RwY1S55upCrj8CrJ8NXjo7EoqEh2+iDCZVY7xUmf1z8ZLUict6 WvQjeOt+vD9rd4sBjlDauriL4dxDfdv0nUCBraOwQic2AnURzr3f324yTQaKHAWpXSU6 49Rg== X-Gm-Message-State: AOAM533vg6TU6fyznMZHNEb+fXUMqJPGbaMrC23Qv90v22Syhz/PyjwG BlrfAL6p3wU5/4e3c2J06uwN9nJWV45oI5w5tW4= X-Google-Smtp-Source: ABdhPJzLYcM2eqZ2Ee6KVcXZy35ktuilWseV1ych94cj0OZmVWGEDaNB2g78NchfB5bgG/nGqrhta+2c3XQ8QMZ30AA= X-Received: by 2002:a9d:12f4:: with SMTP id g107mr10716678otg.352.1590274347163; Sat, 23 May 2020 15:52:27 -0700 (PDT) MIME-Version: 1.0 References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> <83sgfqxztr.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 19:52:14 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000008f10e905a658996b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, Andrea Corallo 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 (-) --0000000000008f10e905a658996b Content-Type: multipart/alternative; boundary="0000000000008f10c705a6589969" --0000000000008f10c705a6589969 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have come up with this patch to reduce the number of files probed when `load' is called.. El s=C3=A1b., 23 may. 2020 a las 15:43, Nicolas B=C3=A9rtolo (< nicolasbertolo@gmail.com>) escribi=C3=B3: > > Why would you have so many directories in your load-path? > > Because I have many Spacemacs layers installed, each installs many packag= es > and each package has its own directory in `package-user-dir`. > > El s=C3=A1b., 23 may. 2020 a las 15:37, Eli Zaretskii () > escribi=C3=B3: > >> > From: Nicolas B=C3=A9rtolo >> > Date: Sat, 23 May 2020 15:29:25 -0300 >> > Cc: Andrea Corallo , 41242@debbugs.gnu.org >> > >> > > If it takes us 32 seconds to run openp, then how many files do we tr= y >> > > to probe? 32 sec is eternity! >> > >> > `load-path' has 380 entries >> >> Is this due to Spacemacs setup, or something else? Why would you have >> so many directories in your load-path? >> > --0000000000008f10c705a6589969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have come up with this patch to reduce the number o= f files
probed when `load' is called..

El s=C3=A1b., 23= may. 2020 a las 15:43, Nicolas B=C3=A9rtolo (<nicolasbertolo@gmail.com>) escribi=C3=B3:
&= gt;=20 Why would you have so many directories in your load-path?

Becaus= e I have many Spacemacs layers installed, each installs many packages
=
and each package has its own directory in `package-user-dir`.

El s=C3=A1b., 23 may. 2020 a las 15:37, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
=
> From: Nicolas = B=C3=A9rtolo <nicolasbertolo@gmail.com>
> Date: Sat, 23 May 2020 15:29:25 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > If it takes us 32 seconds to run openp, then how many files do we= try
> > to probe?=C2=A0 32 sec is eternity!
>
> `load-path' has 380 entries

Is this due to Spacemacs setup, or something else?=C2=A0 Why would you have=
so many directories in your load-path?
--0000000000008f10c705a6589969-- --0000000000008f10e905a658996b Content-Type: application/octet-stream; name="0001-Reduce-the-number-of-files-probed-when-finding-a-lis.patch" Content-Disposition: attachment; filename="0001-Reduce-the-number-of-files-probed-when-finding-a-lis.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kak89wtr0 RnJvbSBlMTlkNDMzNTBlMzBiZDU4MTZkZDhmZDMzYzY3NzAzNTFlYTkwMmI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogU2F0LCAyMyBNYXkgMjAyMCAxODo0 OTo1MiAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIFJlZHVjZSB0aGUgbnVtYmVyIG9mIGZpbGVzIHBy b2JlZCB3aGVuIGZpbmRpbmcgYSBsaXNwIGZpbGUuCgoqIHNyYy9scmVhZC5jIChnZXQtbG9hZC1z dWZmaXhlcyk6IERvIG5vdCBhZGQgYW55IHN1ZmZpeCB0byBmaWxlcyB0aGF0Cm5lZWQgdG8gYmUg bG9hZGVkIGJ5IHRoZSBkeW5hbWljIGxpbmtlci4KKGVmZmVjdGl2ZV9sb2FkX3BhdGgpOiBSZW1v dmUgZnVuY3Rpb24uCihsb2FkKTogRG9uJ3QgYWRkIGFueSBzdWZmaXggaWYgZmlsZSBlbmRzIGlu IGEgc3VmZml4IGFscmVhZHkuCihvcGVucCk6IEFkZCBhIHBhcmFtZXRlciBgYWRkX2Vsbl9kaXJg IHRoYXQgc2hvdWxkIGJlIHVzZWQgd2hlbiB3ZQpkZXNpcmUgdGhlIGRpciBlbHQvZWxuLWhhc2gv IHRvIGJlIHNlYXJjaGVkIGZvciBlYWNoIHBhdGggaW4gYHBhdGhgLgoqIHNyYy9saXNwLmg6IEFk ZCBuZXcgcGFyYW1ldGVyIHRvIG9wZW5wLgoqIHNyYy9jYWxscHJvYy5jOiBBZGQgdGhlIG5ldyBw YXJhbWV0ZXIgdG8gY2FsbHMgdG8gb3BlbnAoKS4KKiBzcmMvY2hhcnNldC5jOiBBZGQgdGhlIG5l dyBwYXJhbWV0ZXIgdG8gY2FsbHMgdG8gb3BlbnAoKS4KKiBzcmMvZW1hY3MuYzogQWRkIHRoZSBu ZXcgcGFyYW1ldGVyIHRvIGNhbGxzIHRvIG9wZW5wKCkuCiogc3JjL2ltYWdlLmM6IEFkZCB0aGUg bmV3IHBhcmFtZXRlciB0byBjYWxscyB0byBvcGVucCgpLgoqIHNyYy9wcm9jZXNzLmM6IEFkZCB0 aGUgbmV3IHBhcmFtZXRlciB0byBjYWxscyB0byBvcGVucCgpLgoqIHNyYy93MzIuYzogQWRkIHRo ZSBuZXcgcGFyYW1ldGVyIHRvIGNhbGxzIHRvIG9wZW5wKCkuCiogc3JjL3czMnByb2MuYzogQWRk IHRoZSBuZXcgcGFyYW1ldGVyIHRvIGNhbGxzIHRvIG9wZW5wKCkuCi0tLQogc3JjL2NhbGxwcm9j LmMgfCAgIDIgKy0KIHNyYy9jaGFyc2V0LmMgIHwgICAyICstCiBzcmMvZW1hY3MuYyAgICB8ICAg MyArLQogc3JjL2ltYWdlLmMgICAgfCAgIDQgKy0KIHNyYy9saXNwLmggICAgIHwgICAyICstCiBz cmMvbHJlYWQuYyAgICB8IDEwMyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0t LS0tLS0tLS0tLS0tCiBzcmMvcHJvY2Vzcy5jICB8ICAgMiArLQogc3JjL3czMi5jICAgICAgfCAg IDIgKy0KIHNyYy93MzJwcm9jLmMgIHwgICAyICstCiA5IGZpbGVzIGNoYW5nZWQsIDcyIGluc2Vy dGlvbnMoKyksIDUwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9jYWxscHJvYy5jIGIv c3JjL2NhbGxwcm9jLmMKaW5kZXggNjVjODU4MzkzYS4uNDIxZTQyZGUxMSAxMDA2NDQKLS0tIGEv c3JjL2NhbGxwcm9jLmMKKysrIGIvc3JjL2NhbGxwcm9jLmMKQEAgLTQzNiw3ICs0MzYsNyBAQCBj YWxsX3Byb2Nlc3MgKHB0cmRpZmZfdCBuYXJncywgTGlzcF9PYmplY3QgKmFyZ3MsIGludCBmaWxl ZmQsCiAgIHsKICAgICBpbnQgb2s7CiAKLSAgICBvayA9IG9wZW5wIChWZXhlY19wYXRoLCBhcmdz WzBdLCBWZXhlY19zdWZmaXhlcywgJnBhdGgsCisgICAgb2sgPSBvcGVucCAoVmV4ZWNfcGF0aCwg YXJnc1swXSwgZmFsc2UsIFZleGVjX3N1ZmZpeGVzLCAmcGF0aCwKIAkJbWFrZV9maXhudW0gKFhf T0spLCBmYWxzZSk7CiAgICAgaWYgKG9rIDwgMCkKICAgICAgIHJlcG9ydF9maWxlX2Vycm9yICgi U2VhcmNoaW5nIGZvciBwcm9ncmFtIiwgYXJnc1swXSk7CmRpZmYgLS1naXQgYS9zcmMvY2hhcnNl dC5jIGIvc3JjL2NoYXJzZXQuYwppbmRleCA4NjM1YWFkM2VkLi5kYTNhY2U3NDNmIDEwMDY0NAot LS0gYS9zcmMvY2hhcnNldC5jCisrKyBiL3NyYy9jaGFyc2V0LmMKQEAgLTQ4Niw3ICs0ODYsNyBA QCBsb2FkX2NoYXJzZXRfbWFwX2Zyb21fZmlsZSAoc3RydWN0IGNoYXJzZXQgKmNoYXJzZXQsIExp c3BfT2JqZWN0IG1hcGZpbGUsCiAgIHB0cmRpZmZfdCBjb3VudCA9IFNQRUNQRExfSU5ERVggKCk7 CiAgIHJlY29yZF91bndpbmRfcHJvdGVjdF9ub3RoaW5nICgpOwogICBzcGVjYmluZCAoUWZpbGVf bmFtZV9oYW5kbGVyX2FsaXN0LCBRbmlsKTsKLSAgZmQgPSBvcGVucCAoVmNoYXJzZXRfbWFwX3Bh dGgsIG1hcGZpbGUsIHN1ZmZpeGVzLCBOVUxMLCBRbmlsLCBmYWxzZSk7CisgIGZkID0gb3BlbnAg KFZjaGFyc2V0X21hcF9wYXRoLCBtYXBmaWxlLCBmYWxzZSwgc3VmZml4ZXMsIE5VTEwsIFFuaWws IGZhbHNlKTsKICAgZnAgPSBmZCA8IDAgPyAwIDogZmRvcGVuIChmZCwgInIiKTsKICAgaWYgKCFm cCkKICAgICB7CmRpZmYgLS1naXQgYS9zcmMvZW1hY3MuYyBiL3NyYy9lbWFjcy5jCmluZGV4IGI3 Yzg5YjQ0ZWMuLmNlN2IyMTBjNmYgMTAwNjQ0Ci0tLSBhL3NyYy9lbWFjcy5jCisrKyBiL3NyYy9l bWFjcy5jCkBAIC00NDksNyArNDQ5LDggQEAgc2V0X2ludm9jYXRpb25fdmFycyAoY2hhciAqYXJn djAsIGNoYXIgY29uc3QgKm9yaWdpbmFsX3B3ZCkKICAgICB7CiAgICAgICBMaXNwX09iamVjdCBm b3VuZDsKICAgICAgIGludCB5ZXMgPSBvcGVucCAoVmV4ZWNfcGF0aCwgVmludm9jYXRpb25fbmFt ZSwKLQkJICAgICAgIFZleGVjX3N1ZmZpeGVzLCAmZm91bmQsIG1ha2VfZml4bnVtIChYX09LKSwg ZmFsc2UpOworCQkgICAgICAgZmFsc2UsIFZleGVjX3N1ZmZpeGVzLCAmZm91bmQsIG1ha2VfZml4 bnVtIChYX09LKSwKKyAgICAgICAgICAgICAgICAgICAgICAgZmFsc2UpOwogICAgICAgaWYgKHll cyA9PSAxKQogCXsKIAkgIC8qIEFkZCAvOiB0byB0aGUgZnJvbnQgb2YgdGhlIG5hbWUKZGlmZiAt LWdpdCBhL3NyYy9pbWFnZS5jIGIvc3JjL2ltYWdlLmMKaW5kZXggYzhhMTkyYWFhZi4uODBlZjgw MTkxMyAxMDA2NDQKLS0tIGEvc3JjL2ltYWdlLmMKKysrIGIvc3JjL2ltYWdlLmMKQEAgLTUwOCw3 ICs1MDgsNyBAQCBpbWFnZV9jcmVhdGVfYml0bWFwX2Zyb21fZmlsZSAoc3RydWN0IGZyYW1lICpm LCBMaXNwX09iamVjdCBmaWxlKQogICAgIH0KIAogICAvKiBTZWFyY2ggYml0bWFwLWZpbGUtcGF0 aCBmb3IgdGhlIGZpbGUsIGlmIGFwcHJvcHJpYXRlLiAgKi8KLSAgaWYgKG9wZW5wIChWeF9iaXRt YXBfZmlsZV9wYXRoLCBmaWxlLCBRbmlsLCAmZm91bmQsCisgIGlmIChvcGVucCAoVnhfYml0bWFw X2ZpbGVfcGF0aCwgZmlsZSwgZmFsc2UsIFFuaWwsICZmb3VuZCwKIAkgICAgIG1ha2VfZml4bnVt IChSX09LKSwgZmFsc2UpCiAgICAgICA8IDApCiAgICAgcmV0dXJuIC0xOwpAQCAtMjk4Myw3ICsy OTgzLDcgQEAgaW1hZ2VfZmluZF9pbWFnZV9mZCAoTGlzcF9PYmplY3QgZmlsZSwgaW50ICpwZmQp CiAJCSAgICAgICBWeF9iaXRtYXBfZmlsZV9wYXRoKTsKIAogICAvKiBUcnkgdG8gZmluZCBGSUxF IGluIGRhdGEtZGlyZWN0b3J5L2ltYWdlcywgdGhlbiB4LWJpdG1hcC1maWxlLXBhdGguICAqLwot ICBmZCA9IG9wZW5wIChzZWFyY2hfcGF0aCwgZmlsZSwgUW5pbCwgJmZpbGVfZm91bmQsCisgIGZk ID0gb3BlbnAgKHNlYXJjaF9wYXRoLCBmaWxlLCBmYWxzZSwgUW5pbCwgJmZpbGVfZm91bmQsCiAJ ICAgICAgcGZkID8gUXQgOiBtYWtlX2ZpeG51bSAoUl9PSyksIGZhbHNlKTsKICAgaWYgKGZkID49 IDAgfHwgZmQgPT0gLTIpCiAgICAgewpkaWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNw LmgKaW5kZXggM2U3ZTUxZjgzOS4uMGJmMmNmZDc0MSAxMDA2NDQKLS0tIGEvc3JjL2xpc3AuaAor KysgYi9zcmMvbGlzcC5oCkBAIC00MDk2LDcgKzQwOTYsNyBAQCBMT0FESElTVF9BVFRBQ0ggKExp c3BfT2JqZWN0IHgpCiBleHRlcm4gYm9vbCBzdWZmaXhfcCAoTGlzcF9PYmplY3QsIGNvbnN0IGNo YXIgKik7CiBleHRlcm4gTGlzcF9PYmplY3Qgc2F2ZV9tYXRjaF9kYXRhX2xvYWQgKExpc3BfT2Jq ZWN0LCBMaXNwX09iamVjdCwgTGlzcF9PYmplY3QsCiAJCQkJCSBMaXNwX09iamVjdCwgTGlzcF9P YmplY3QpOwotZXh0ZXJuIGludCBvcGVucCAoTGlzcF9PYmplY3QsIExpc3BfT2JqZWN0LCBMaXNw X09iamVjdCwKK2V4dGVybiBpbnQgb3BlbnAgKExpc3BfT2JqZWN0LCBMaXNwX09iamVjdCwgYm9v bCwgTGlzcF9PYmplY3QsCiAgICAgICAgICAgICAgICAgICBMaXNwX09iamVjdCAqLCBMaXNwX09i amVjdCwgYm9vbCk7CiBlbnVtIHsgUzJOX0lHTk9SRV9UUkFJTElORyA9IDEgfTsKIGV4dGVybiBM aXNwX09iamVjdCBzdHJpbmdfdG9fbnVtYmVyIChjaGFyIGNvbnN0ICosIGludCwgcHRyZGlmZl90 ICopOwpkaWZmIC0tZ2l0IGEvc3JjL2xyZWFkLmMgYi9zcmMvbHJlYWQuYwppbmRleCAwMWYzNTlj YTU4Li45YzNhNjgyYmI3IDEwMDY0NAotLS0gYS9zcmMvbHJlYWQuYworKysgYi9zcmMvbHJlYWQu YwpAQCAtMTA1NiwzMyArMTA1NiwyNSBAQCBERUZVTiAoImdldC1sb2FkLXN1ZmZpeGVzIiwgRmdl dF9sb2FkX3N1ZmZpeGVzLCBTZ2V0X2xvYWRfc3VmZml4ZXMsIDAsIDAsIDAsCiAgICAgewogICAg ICAgTGlzcF9PYmplY3QgZXh0cyA9IFZsb2FkX2ZpbGVfcmVwX3N1ZmZpeGVzOwogICAgICAgTGlz cF9PYmplY3Qgc3VmZml4ID0gWENBUiAoc3VmZml4ZXMpOwotICAgICAgRk9SX0VBQ0hfVEFJTCAo ZXh0cykKLQlsc3QgPSBGY29ucyAoY29uY2F0MiAoc3VmZml4LCBYQ0FSIChleHRzKSksIGxzdCk7 CisgICAgICBpZiAoZmFsc2UKKyNpZmRlZiBIQVZFX01PRFVMRVMKKyAgICAgICAgICB8fCBzdHJj bXAgKE1PRFVMRVNfU1VGRklYLCBTU0RBVEEgKHN1ZmZpeCkpID09IDAKKyNpZmRlZiBNT0RVTEVT X1NFQ09OREFSWV9TVUZGSVgKKyAgICAgICAgICB8fCBzdHJjbXAgKE1PRFVMRVNfU0VDT05EQVJZ X1NVRkZJWCwgU1NEQVRBIChzdWZmaXgpKSA9PSAwCisjZW5kaWYKKyNlbmRpZgorI2lmZGVmIEhB VkVfTkFUSVZFX0NPTVAKKyAgICAgICAgICB8fCBzdHJjbXAgKE5BVElWRV9FTElTUF9TVUZGSVgs IFNTREFUQSAoc3VmZml4KSkgPT0gMAorI2VuZGlmCisgICAgICAgICAgKQorCWxzdCA9IEZjb25z IChzdWZmaXgsIGxzdCk7CisgICAgICBlbHNlCisgICAgICAgIEZPUl9FQUNIX1RBSUwgKGV4dHMp CisgICAgICAgICAgbHN0ID0gRmNvbnMgKGNvbmNhdDIgKHN1ZmZpeCwgWENBUiAoZXh0cykpLCBs c3QpOwogICAgIH0KICAgcmV0dXJuIEZucmV2ZXJzZSAobHN0KTsKIH0KIAotc3RhdGljIExpc3Bf T2JqZWN0Ci1lZmZlY3RpdmVfbG9hZF9wYXRoICh2b2lkKQotewotI2lmbmRlZiBIQVZFX05BVElW RV9DT01QCi0gIHJldHVybiBWbG9hZF9wYXRoOwotI2Vsc2UKLSAgTGlzcF9PYmplY3QgbHAgPSBW bG9hZF9wYXRoOwotICBMaXNwX09iamVjdCBuZXdfbHAgPSBRbmlsOwotICBGT1JfRUFDSF9UQUlM IChscCkKLSAgICB7Ci0gICAgICBMaXNwX09iamVjdCBlbCA9IFhDQVIgKGxwKTsKLSAgICAgIG5l d19scCA9Ci0JRmNvbnMgKGNvbmNhdDIgKEZmaWxlX25hbWVfYXNfZGlyZWN0b3J5IChlbCksCi0J CQlWY29tcF9uYXRpdmVfcGF0aF9wb3N0Zml4KSwKLQkgICAgICAgbmV3X2xwKTsKLSAgICAgIG5l d19scCA9IEZjb25zIChlbCwgbmV3X2xwKTsKLSAgICB9Ci0gIHJldHVybiBGbnJldmVyc2UgKG5l d19scCk7Ci0jZW5kaWYKLX0KLQogLyogUmV0dXJuIHRydWUgaWYgU1RSSU5HIGVuZHMgd2l0aCBT VUZGSVguICAqLwogYm9vbAogc3VmZml4X3AgKExpc3BfT2JqZWN0IHN0cmluZywgY29uc3QgY2hh ciAqc3VmZml4KQpAQCAtMTIxNyw2ICsxMjA5LDkgQEAgREVGVU4gKCJsb2FkIiwgRmxvYWQsIFNs b2FkLCAxLCA1LCAwLAogI2lmZGVmIE1PRFVMRVNfU0VDT05EQVJZX1NVRkZJWAogICAgICAgICAg ICAgICB8fCBzdWZmaXhfcCAoZmlsZSwgTU9EVUxFU19TRUNPTkRBUllfU1VGRklYKQogI2VuZGlm CisjZW5kaWYKKyNpZmRlZiBIQVZFX05BVElWRV9DT01QCisgICAgICAgICAgICAgIHx8IHN1ZmZp eF9wIChmaWxlLCBOQVRJVkVfRUxJU1BfU1VGRklYKQogI2VuZGlmCiAJICAgICAgKQogCSAgICBt dXN0X3N1ZmZpeCA9IFFuaWw7CkBAIC0xMjM2LDggKzEyMzEsOCBAQCBERUZVTiAoImxvYWQiLCBG bG9hZCwgU2xvYWQsIDEsIDUsIDAsCiAJfQogCiAgICAgICBmZCA9Ci0Jb3BlbnAgKGVmZmVjdGl2 ZV9sb2FkX3BhdGggKCksIGZpbGUsIHN1ZmZpeGVzLCAmZm91bmQsIFFuaWwsCi0JICAgICAgIGxv YWRfcHJlZmVyX25ld2VyKTsKKwlvcGVucCAoVmxvYWRfcGF0aCwgZmlsZSwgdHJ1ZSwgc3VmZml4 ZXMsICZmb3VuZCwgUW5pbCwKKyAgICAgICAgICAgICAgIGxvYWRfcHJlZmVyX25ld2VyKTsKICAg ICB9CiAKICAgaWYgKGZkID09IC0xKQpAQCAtMTYwMCw3ICsxNTk1LDcgQEAgREVGVU4gKCJsb2Nh dGUtZmlsZS1pbnRlcm5hbCIsIEZsb2NhdGVfZmlsZV9pbnRlcm5hbCwgU2xvY2F0ZV9maWxlX2lu dGVybmFsLCAyLAogICAoTGlzcF9PYmplY3QgZmlsZW5hbWUsIExpc3BfT2JqZWN0IHBhdGgsIExp c3BfT2JqZWN0IHN1ZmZpeGVzLCBMaXNwX09iamVjdCBwcmVkaWNhdGUpCiB7CiAgIExpc3BfT2Jq ZWN0IGZpbGU7Ci0gIGludCBmZCA9IG9wZW5wIChwYXRoLCBmaWxlbmFtZSwgc3VmZml4ZXMsICZm aWxlLCBwcmVkaWNhdGUsIGZhbHNlKTsKKyAgaW50IGZkID0gb3BlbnAgKHBhdGgsIGZpbGVuYW1l LCBRbmlsLCBzdWZmaXhlcywgJmZpbGUsIHByZWRpY2F0ZSwgZmFsc2UpOwogICBpZiAoTklMUCAo cHJlZGljYXRlKSAmJiBmZCA+PSAwKQogICAgIGVtYWNzX2Nsb3NlIChmZCk7CiAgIHJldHVybiBm aWxlOwpAQCAtMTYzMyw4ICsxNjI4LDkgQEAgREVGVU4gKCJsb2NhdGUtZmlsZS1pbnRlcm5hbCIs IEZsb2NhdGVfZmlsZV9pbnRlcm5hbCwgU2xvY2F0ZV9maWxlX2ludGVybmFsLCAyLAogICAgb3Ig aWYgYSBub24tbmlsIGFuZCBub24tdCBQUkVESUNBVEUgaXMgc3BlY2lmaWVkLiAgKi8KIAogaW50 Ci1vcGVucCAoTGlzcF9PYmplY3QgcGF0aCwgTGlzcF9PYmplY3Qgc3RyLCBMaXNwX09iamVjdCBz dWZmaXhlcywKLSAgICAgICBMaXNwX09iamVjdCAqc3RvcmVwdHIsIExpc3BfT2JqZWN0IHByZWRp Y2F0ZSwgYm9vbCBuZXdlcikKK29wZW5wIChMaXNwX09iamVjdCBwYXRoLCBMaXNwX09iamVjdCBz dHIsIGJvb2wgZml4X2xvYWRfcGF0aHMsCisgICAgICAgTGlzcF9PYmplY3Qgc3VmZml4ZXMsIExp c3BfT2JqZWN0ICpzdG9yZXB0ciwgTGlzcF9PYmplY3QgcHJlZGljYXRlLAorICAgICAgIGJvb2wg bmV3ZXIpCiB7CiAgIHB0cmRpZmZfdCBmbl9zaXplID0gMTAwOwogICBjaGFyIGJ1ZlsxMDBdOwpA QCAtMTY0Myw3ICsxNjM5LDcgQEAgb3BlbnAgKExpc3BfT2JqZWN0IHBhdGgsIExpc3BfT2JqZWN0 IHN0ciwgTGlzcF9PYmplY3Qgc3VmZml4ZXMsCiAgIHB0cmRpZmZfdCB3YW50X2xlbmd0aDsKICAg TGlzcF9PYmplY3QgZmlsZW5hbWU7CiAgIExpc3BfT2JqZWN0IHN0cmluZywgdGFpbCwgZW5jb2Rl ZF9mbiwgc2F2ZV9zdHJpbmc7Ci0gIHB0cmRpZmZfdCBtYXhfc3VmZml4X2xlbiA9IDA7CisgIHB0 cmRpZmZfdCBtYXhfZXh0cmFfbGVuID0gMDsKICAgaW50IGxhc3RfZXJybm8gPSBFTk9FTlQ7CiAg IGludCBzYXZlX2ZkID0gLTE7CiAgIFVTRV9TQUZFX0FMTE9DQTsKQEAgLTE2NTgsOCArMTY1NCwx NSBAQCBvcGVucCAoTGlzcF9PYmplY3QgcGF0aCwgTGlzcF9PYmplY3Qgc3RyLCBMaXNwX09iamVj dCBzdWZmaXhlcywKICAgRk9SX0VBQ0hfVEFJTF9TQUZFICh0YWlsKQogICAgIHsKICAgICAgIENI RUNLX1NUUklOR19DQVIgKHRhaWwpOwotICAgICAgbWF4X3N1ZmZpeF9sZW4gPSBtYXggKG1heF9z dWZmaXhfbGVuLAotCQkJICAgIFNCWVRFUyAoWENBUiAodGFpbCkpKTsKKyAgICAgIGNoYXIgKiBz dWYgPSBTU0RBVEEgKFhDQVIgKHRhaWwpKTsKKyAgICAgIHB0cmRpZmZfdCBsZW4gPSBTQllURVMg KFhDQVIgKHRhaWwpKTsKKyAgICAgIGlmIChmaXhfbG9hZF9wYXRocyAmJiBzdHJjbXAoTkFUSVZF X0VMSVNQX1NVRkZJWCwgc3VmKSA9PSAwKQorICAgICAgICB7CisgICAgICAgICAgQ0hFQ0tfU1RS SU5HIChWY29tcF9uYXRpdmVfcGF0aF9wb3N0Zml4KTsKKyAgICAgICAgICBsZW4gKz0gMjsKKyAg ICAgICAgICBsZW4gKz0gU0JZVEVTIChWY29tcF9uYXRpdmVfcGF0aF9wb3N0Zml4KTsKKyAgICAg ICAgfQorICAgICAgbWF4X2V4dHJhX2xlbiA9IG1heCAobWF4X2V4dHJhX2xlbiwgbGVuKTsKICAg ICB9CiAKICAgc3RyaW5nID0gZmlsZW5hbWUgPSBlbmNvZGVkX2ZuID0gc2F2ZV9zdHJpbmcgPSBR bmlsOwpAQCAtMTY3Nyw3ICsxNjgwLDcgQEAgb3BlbnAgKExpc3BfT2JqZWN0IHBhdGgsIExpc3Bf T2JqZWN0IHN0ciwgTGlzcF9PYmplY3Qgc3VmZml4ZXMsCiAgICAgIGV4ZWN1dGFibGUuICovCiAg IEZPUl9FQUNIX1RBSUxfU0FGRSAocGF0aCkKICAgIHsKLSAgICBwdHJkaWZmX3QgYmFzZWxlbiwg cHJlZml4bGVuOworICAgIHB0cmRpZmZfdCBkaXJuYW1lbGVuLCBwcmVmaXhsZW4sIGJhc2VuYW1l d2V4dF9sZW47CiAKICAgICBpZiAoRVEgKHBhdGgsIGp1c3RfdXNlX3N0cikpCiAgICAgICBmaWxl bmFtZSA9IHN0cjsKQEAgLTE2OTQsMjIgKzE2OTcsMjcgQEAgb3BlbnAgKExpc3BfT2JqZWN0IHBh dGgsIExpc3BfT2JqZWN0IHN0ciwgTGlzcF9PYmplY3Qgc3VmZml4ZXMsCiAJICBjb250aW51ZTsK ICAgICAgIH0KIAorCiAgICAgLyogQ2FsY3VsYXRlIG1heGltdW0gbGVuZ3RoIG9mIGFueSBmaWxl bmFtZSBtYWRlIGZyb20KICAgICAgICB0aGlzIHBhdGggZWxlbWVudC9zcGVjaWZpZWQgZmlsZSBu YW1lIGFuZCBhbnkgcG9zc2libGUgc3VmZml4LiAgKi8KLSAgICB3YW50X2xlbmd0aCA9IG1heF9z dWZmaXhfbGVuICsgU0JZVEVTIChmaWxlbmFtZSk7CisgICAgd2FudF9sZW5ndGggPSBtYXhfZXh0 cmFfbGVuICsgU0JZVEVTIChmaWxlbmFtZSk7CiAgICAgaWYgKGZuX3NpemUgPD0gd2FudF9sZW5n dGgpCiAgICAgICB7CiAJZm5fc2l6ZSA9IDEwMCArIHdhbnRfbGVuZ3RoOwogCWZuID0gU0FGRV9B TExPQ0EgKGZuX3NpemUpOwogICAgICAgfQogCisgICAgTGlzcF9PYmplY3QgZGlybmFtZXdzbGFz aCA9IEZmaWxlX25hbWVfZGlyZWN0b3J5KGZpbGVuYW1lKTsKKyAgICBMaXNwX09iamVjdCBiYXNl bmFtZXdleHQgPSBGZmlsZV9uYW1lX25vbmRpcmVjdG9yeShmaWxlbmFtZSk7CisKICAgICAvKiBD b3B5IEZJTEVOQU1FJ3MgZGF0YSB0byBGTiBidXQgcmVtb3ZlIHN0YXJ0aW5nIC86IGlmIGFueS4g ICovCi0gICAgcHJlZml4bGVuID0gKChTQ0hBUlMgKGZpbGVuYW1lKSA+IDIKLQkJICAmJiBTUkVG IChmaWxlbmFtZSwgMCkgPT0gJy8nCi0JCSAgJiYgU1JFRiAoZmlsZW5hbWUsIDEpID09ICc6JykK KyAgICBwcmVmaXhsZW4gPSAoKFNDSEFSUyAoZGlybmFtZXdzbGFzaCkgPiAyCisJCSAgJiYgU1JF RiAoZGlybmFtZXdzbGFzaCwgMCkgPT0gJy8nCisJCSAgJiYgU1JFRiAoZGlybmFtZXdzbGFzaCwg MSkgPT0gJzonKQogCQkgPyAyIDogMCk7Ci0gICAgYmFzZWxlbiA9IFNCWVRFUyAoZmlsZW5hbWUp IC0gcHJlZml4bGVuOwotICAgIG1lbWNweSAoZm4sIFNEQVRBIChmaWxlbmFtZSkgKyBwcmVmaXhs ZW4sIGJhc2VsZW4pOworICAgIGRpcm5hbWVsZW4gPSBTQllURVMgKGRpcm5hbWV3c2xhc2gpIC0g cHJlZml4bGVuOworICAgIGJhc2VuYW1ld2V4dF9sZW4gPSBTQllURVMgKGJhc2VuYW1ld2V4dCk7 CisgICAgbWVtY3B5IChmbiwgU0RBVEEgKGRpcm5hbWV3c2xhc2gpICsgcHJlZml4bGVuLCBkaXJu YW1lbGVuKTsKIAogICAgIC8qIExvb3Agb3ZlciBzdWZmaXhlcy4gICovCiAgICAgQVVUT19MSVNU MSAoZW1wdHlfc3RyaW5nX29ubHksIGVtcHR5X3VuaWJ5dGVfc3RyaW5nKTsKQEAgLTE3MTksMTAg KzE3MjcsMjMgQEAgb3BlbnAgKExpc3BfT2JqZWN0IHBhdGgsIExpc3BfT2JqZWN0IHN0ciwgTGlz cF9PYmplY3Qgc3VmZml4ZXMsCiAJTGlzcF9PYmplY3Qgc3VmZml4ID0gWENBUiAodGFpbCk7CiAJ cHRyZGlmZl90IGZubGVuLCBsc3VmZml4ID0gU0JZVEVTIChzdWZmaXgpOwogCUxpc3BfT2JqZWN0 IGhhbmRsZXI7CisgICAgICAgIGJvb2wgYWRkX25hdGl2ZV9jb21wX2RpciA9IGZpeF9sb2FkX3Bh dGhzICYmCisgICAgICAgICAgKHN0cmNtcChTU0RBVEEoc3VmZml4KSwgTkFUSVZFX0VMSVNQX1NV RkZJWCkgPT0gMCk7CisgICAgICAgIHB0cmRpZmZfdCBsbWlkZGxlZGlyID0gYWRkX25hdGl2ZV9j b21wX2RpciA/CisgICAgICAgICAgICBTQllURVMoVmNvbXBfbmF0aXZlX3BhdGhfcG9zdGZpeCkg KyAxIDogMDsKKworICAgICAgICBpZiAoYWRkX25hdGl2ZV9jb21wX2RpcikKKyAgICAgICAgICB7 CisgICAgICAgICAgICBtZW1jcHkoZm4gKyBkaXJuYW1lbGVuLCBTREFUQShWY29tcF9uYXRpdmVf cGF0aF9wb3N0Zml4KSwKKyAgICAgICAgICAgICAgICAgICBsbWlkZGxlZGlyIC0gMSk7CisgICAg ICAgICAgICBmbltkaXJuYW1lbGVuKyhsbWlkZGxlZGlyLTEpXSA9ICcvJzsKKyAgICAgICAgICB9 CiAKLQkvKiBNYWtlIGNvbXBsZXRlIGZpbGVuYW1lIGJ5IGFwcGVuZGluZyBTVUZGSVguICAqLwot CW1lbWNweSAoZm4gKyBiYXNlbGVuLCBTREFUQSAoc3VmZml4KSwgbHN1ZmZpeCArIDEpOwotCWZu bGVuID0gYmFzZWxlbiArIGxzdWZmaXg7CisgICAgICAgIG1lbWNweSAoZm4gKyBkaXJuYW1lbGVu ICsgbG1pZGRsZWRpciwgU0RBVEEgKGJhc2VuYW1ld2V4dCksIGJhc2VuYW1ld2V4dF9sZW4pOwor ICAgICAgICAvKiBNYWtlIGNvbXBsZXRlIGZpbGVuYW1lIGJ5IGFwcGVuZGluZyBTVUZGSVguICAq LworICAgICAgICBtZW1jcHkgKGZuICsgZGlybmFtZWxlbiArIGxtaWRkbGVkaXIgKyBiYXNlbmFt ZXdleHRfbGVuLAorICAgICAgICAgICAgICAgIFNEQVRBIChzdWZmaXgpLCBsc3VmZml4ICsgMSk7 CisgICAgICAgIGZubGVuID0gZGlybmFtZWxlbiArIGxtaWRkbGVkaXIgKyBiYXNlbmFtZXdleHRf bGVuICsgbHN1ZmZpeDsKIAogCS8qIENoZWNrIHRoYXQgdGhlIGZpbGUgZXhpc3RzIGFuZCBpcyBu b3QgYSBkaXJlY3RvcnkuICAqLwogCS8qIFdlIHVzZWQgdG8gb25seSBjaGVjayBmb3IgaGFuZGxl cnMgb24gbm9uLWFic29sdXRlIGZpbGUgbmFtZXM6CmRpZmYgLS1naXQgYS9zcmMvcHJvY2Vzcy5j IGIvc3JjL3Byb2Nlc3MuYwppbmRleCA2ZTViY2YzMDdhLi5lMDkyZmEwYTBjIDEwMDY0NAotLS0g YS9zcmMvcHJvY2Vzcy5jCisrKyBiL3NyYy9wcm9jZXNzLmMKQEAgLTE5MDMsNyArMTkwMyw3IEBA IERFRlVOICgibWFrZS1wcm9jZXNzIiwgRm1ha2VfcHJvY2VzcywgU21ha2VfcHJvY2VzcywgMCwg TUFOWSwgMCwKIAkgICAgICAgJiYgSVNfREVWSUNFX1NFUCAoU1JFRiAocHJvZ3JhbSwgMSkpKSkK IAl7CiAJICB0ZW0gPSBRbmlsOwotCSAgb3BlbnAgKFZleGVjX3BhdGgsIHByb2dyYW0sIFZleGVj X3N1ZmZpeGVzLCAmdGVtLAorCSAgb3BlbnAgKFZleGVjX3BhdGgsIHByb2dyYW0sIGZhbHNlLCBW ZXhlY19zdWZmaXhlcywgJnRlbSwKIAkJIG1ha2VfZml4bnVtIChYX09LKSwgZmFsc2UpOwogCSAg aWYgKE5JTFAgKHRlbSkpCiAJICAgIHJlcG9ydF9maWxlX2Vycm9yICgiU2VhcmNoaW5nIGZvciBw cm9ncmFtIiwgcHJvZ3JhbSk7CmRpZmYgLS1naXQgYS9zcmMvdzMyLmMgYi9zcmMvdzMyLmMKaW5k ZXggZmQxZjBlMDU5ZS4uMzYyMmE1NTVkNyAxMDA2NDQKLS0tIGEvc3JjL3czMi5jCisrKyBiL3Ny Yy93MzIuYwpAQCAtMTAxNzcsNyArMTAxNzcsNyBAQCBjaGVja193aW5kb3dzX2luaXRfZmlsZSAo dm9pZCkKIAkgbmVlZCB0byBFTkNPREVfRklMRSBoZXJlLCBidXQgd2UgZG8gbmVlZCB0byBjb252 ZXJ0IHRoZSBmaWxlCiAJIG5hbWVzIGZyb20gVVRGLTggdG8gQU5TSS4gICovCiAgICAgICBpbml0 X2ZpbGUgPSBidWlsZF9zdHJpbmcgKCJ0ZXJtL3czMi13aW4iKTsKLSAgICAgIGZkID0gb3BlbnAg KFZsb2FkX3BhdGgsIGluaXRfZmlsZSwgRmdldF9sb2FkX3N1ZmZpeGVzICgpLCBOVUxMLCBRbmls LCAwKTsKKyAgICAgIGZkID0gb3BlbnAgKFZsb2FkX3BhdGgsIGluaXRfZmlsZSwgdHJ1ZSwgRmdl dF9sb2FkX3N1ZmZpeGVzICgpLCBOVUxMLCBRbmlsLCAwKTsKICAgICAgIGlmIChmZCA8IDApCiAJ ewogCSAgTGlzcF9PYmplY3QgbG9hZF9wYXRoX3ByaW50ID0gRnByaW4xX3RvX3N0cmluZyAoVmxv YWRfcGF0aCwgUW5pbCk7CmRpZmYgLS1naXQgYS9zcmMvdzMycHJvYy5jIGIvc3JjL3czMnByb2Mu YwppbmRleCAxNmUzMmU0YzU4Li44NWYyY2NmMDE2IDEwMDY0NAotLS0gYS9zcmMvdzMycHJvYy5j CisrKyBiL3NyYy93MzJwcm9jLmMKQEAgLTE5MTgsNyArMTkxOCw3IEBAIHN5c19zcGF3bnZlIChp bnQgbW9kZSwgY2hhciAqY21kbmFtZSwgY2hhciAqKmFyZ3YsIGNoYXIgKiplbnZwKQogICAgIHsK ICAgICAgIHByb2dyYW0gPSBidWlsZF9zdHJpbmcgKGNtZG5hbWUpOwogICAgICAgZnVsbCA9IFFu aWw7Ci0gICAgICBvcGVucCAoVmV4ZWNfcGF0aCwgcHJvZ3JhbSwgVmV4ZWNfc3VmZml4ZXMsICZm dWxsLCBtYWtlX2ZpeG51bSAoWF9PSyksIDApOworICAgICAgb3BlbnAgKFZleGVjX3BhdGgsIHBy b2dyYW0sIGZhbHNlLCBWZXhlY19zdWZmaXhlcywgJmZ1bGwsIG1ha2VfZml4bnVtIChYX09LKSwg MCk7CiAgICAgICBpZiAoTklMUCAoZnVsbCkpCiAJewogCSAgZXJybm8gPSBFSU5WQUw7Ci0tIAoy LjI1LjEud2luZG93cy4xCgo= --0000000000008f10e905a658996b-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 18:58:55 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 22:58:55 +0000 Received: from localhost ([127.0.0.1]:36017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd6U-0008Cc-KL for submit@debbugs.gnu.org; Sat, 23 May 2020 18:58:55 -0400 Received: from mx.sdf.org ([205.166.94.20]:64192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd6S-0008CT-2g for 41242@debbugs.gnu.org; Sat, 23 May 2020 18:58:53 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04NMwo23019830 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 23 May 2020 22:58:51 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04NMwo67004327; Sat, 23 May 2020 22:58:50 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Sat, 23 May 2020 22:58:50 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 16:26:57 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Hi Nicolas, following some comments on - Improve handling of native compilation etc. Please review all the GNU code-style of this diff. I've annotated some to be fixed but there are quite a number more of fixes of the same kind to be done. > When closing emacs will inspect all directories from which it loaded > native compilation units. If it finds a ".eln.old" file it will try to > delete it, if it fails that means that another Emacs instance is using it. > > When compiling a file we rename the file that was in the output path > in case it has been loaded into another Emacs instance. > > When deleting a package we move any ".eln" or ".eln.old" files in the > package folder that we can't delete to `package-user-dir`. Emacs will > check that directory when closing and delete them. > > * lisp/emacs-lisp/comp.el (comp--replace-output-file): Function called > from C code to finish the compilation process. It performs renaming of > the old file if necessary. > * lisp/emacs-lisp/package.el (package--delete-directory): Function to > delete a package directory. It moves native compilation units that it > can't delete to `package-user-dir'. > * src/alloc.c (cleanup_vector): Call dispose_comp_unit(). > (garbage_collect): Call finish_delayed_disposal_of_comp_units(). > * src/comp.c: Restore the signal mask using unwind-protect. Store > loaded native compilation units in a hash table for disposal on > close. Store filenames of native compilation units GC'd in a linked > list to finish their disposal when the GC is over. Please annotate in the changelog the new functions ex: finish_delayed_disposal_of_comp_units, dispose_all_remaining_comp_units, register_native_comp_unit are missing. > * src/comp.h: Introduce cfile member in Lisp_Native_Comp_Unit. > Add declarations of functions that: clean directories of unused native > compilation units, handle disposal of native compilation units. > * src/emacs.c (kill-emacs): Dispose all remaining compilation units > right right before calling exit(). > * src/eval.c (internal_condition_case_3, internal_condition_case_4): > Add functions. > * src/lisp.h (internal_condition_case_3, internal_condition_case_4): > Add functions. > * src/pdumper.c (dump_do_dump_relocation): Set cfile to a copy of the > Lisp string specifying the file path. > diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el > index 012baf2560..1fb4cd98c0 100644 > --- a/lisp/emacs-lisp/comp.el > +++ b/lisp/emacs-lisp/comp.el > @@ -2183,6 +2183,31 @@ comp-hint-cons > > ;; Some entry point support code. > > +(defun comp--replace-output-file (outfile tmpfile) > + "Replace OUTFILE with TMPFILE taking the necessary steps when > +dealing with shared libraries that may be loaded into Emacs" > + (cond ((eq 'windows-nt system-type) > + (ignore-errors (delete-file outfile)) > + (let ((retry t)) > + (while retry > + (setf retry nil) > + (condition-case _ > + (progn > + ;; outfile maybe recreated by another Emacs in > + ;; between the following two rename-file calls > + (if (file-exists-p outfile) > + (rename-file outfile (make-temp-file-internal > + (file-name-sans-extension outfile) > + nil ".eln.old" nil) Isn't better to just add .old? So we will have cases of foo.eln.old.old instead of foo.eln.old.eln.old ? > + t)) > + (rename-file tmpfile outfile nil)) > + (file-already-exists (setf retry t)))))) > + ;; Remove the old eln instead of copying the new one into it > + ;; to get a new inode and prevent crashes in case the old one > + ;; is currently loaded. > + (t (delete-file outfile) > + (rename-file tmpfile outfile)))) > + > (defvar comp-files-queue () > "List of Elisp files to be compiled.") > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > index 95659840ad..c1c54b3c9a 100644 > --- a/lisp/emacs-lisp/package.el > +++ b/lisp/emacs-lisp/package.el > @@ -2184,6 +2184,31 @@ If some packages are not installed propose to install them." > (equal (cadr (assq (package-desc-name pkg) package-alist)) > pkg)) > > +(defun package--delete-directory (dir) > + "Delete DIR recursively. > +In Windows move .eln and .eln.old files that can not be deleted to `package-user-dir'." 80 column lines limit. I think also this should be transparent when native-comp-available-p say native comp is not available (for now compiler and load machinery are bundled). > + (cond ((eq 'windows-nt system-type) > + (let ((retry t)) > + (while retry > + (setf retry nil) > + (condition-case err > + (delete-directory dir t) > + (file-error > + (if (and (string= "Removing old name" (cadr err)) > + (string= "Permission denied" (caddr err)) > + (or (string-suffix-p ".eln" (cadddr err)) > + (string-suffix-p ".eln.old" (cadddr err)))) I think would be good to destructure err using something like cl-destructuring-bind or pcase or even just using a let + some naming to make this more readable. > + (progn > + (rename-file (cadddr err) > + (make-temp-file-internal > + (concat package-user-dir > + (file-name-base (cadddr err))) > + nil ".eln.old" nil) > + t) > + (setf retry t)) > + (signal (car err) (cdr err)))))))) > + (t (delete-directory dir t)))) > + > (defun package-delete (pkg-desc &optional force nosave) > "Delete package PKG-DESC. > > @@ -2236,7 +2261,7 @@ If NOSAVE is non-nil, the package is not removed from > (package-desc-name pkg-used-elsewhere-by))) > (t > (add-hook 'post-command-hook #'package-menu--post-refresh) > - (delete-directory dir t) > + (package--delete-directory dir) > ;; Remove NAME-VERSION.signed and NAME-readme.txt files. > ;; > ;; NAME-readme.txt files are no longer created, but they > diff --git a/src/alloc.c b/src/alloc.c > index d6ba4d9790..420168ec4d 100644 > --- a/src/alloc.c > +++ b/src/alloc.c > @@ -3119,8 +3119,7 @@ cleanup_vector (struct Lisp_Vector *vector) > { > struct Lisp_Native_Comp_Unit *cu = > PSEUDOVEC_STRUCT (vector, Lisp_Native_Comp_Unit); > - eassert (cu->handle); > - dynlib_close (cu->handle); > + dispose_comp_unit (cu, true); > } > } > > @@ -6117,6 +6116,8 @@ garbage_collect (void) > if (tot_after < tot_before) > malloc_probe (min (tot_before - tot_after, SIZE_MAX)); > } > + > + finish_delayed_disposal_of_comp_units (); Could you describe why we need to call this each garbage collection? Isn't sufficient to do it when emacs is exiting? > } > > DEFUN ("garbage-collect", Fgarbage_collect, Sgarbage_collect, 0, 0, "", > diff --git a/src/comp.c b/src/comp.c > index dd45599cc4..77c3006c56 100644 > --- a/src/comp.c > +++ b/src/comp.c > @@ -413,6 +413,10 @@ load_gccjit_if_necessary (bool mandatory) > #define CALL1I(fun, arg) \ > CALLN (Ffuncall, intern_c_string (STR (fun)), arg) > > +/* Like call2 but stringify and intern. */ > +#define CALL2I(fun, arg1, arg2) \ > + CALLN (Ffuncall, intern_c_string (STR (fun)), arg1, arg2) > + > #define DECL_BLOCK(name, func) \ > gcc_jit_block *(name) = \ > gcc_jit_function_new_block ((func), STR (name)) > @@ -3828,6 +3832,14 @@ DEFUN ("comp--release-ctxt", Fcomp__release_ctxt, Scomp__release_ctxt, > return Qt; > } > > +sigset_t oldset; I think we have all static data at the top. That said this is unclear to me because in comp--compile-ctxt-to-file oldset is automatic and shadows this static, so I think we'll save in the the automatic and later we just restore the (always zeroed) static one. > +static void restore_sigmask(void) ^^^ space > +{ > + pthread_sigmask (SIG_SETMASK, &oldset, 0); > + unblock_input (); > +} > + > DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, > Scomp__compile_ctxt_to_file, > 1, 1, 0, > @@ -3849,6 +3861,8 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, > CALL1I (comp-data-container-idx, CALL1I (comp-ctxt-d-ephemeral, Vcomp_ctxt)); > > sigset_t oldset; > + ptrdiff_t count; > + > if (!noninteractive) > { > sigset_t blocked; > @@ -3861,6 +3875,8 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, > sigaddset (&blocked, SIGIO); > #endif > pthread_sigmask (SIG_BLOCK, &blocked, &oldset); > + count = SPECPDL_INDEX (); > + record_unwind_protect_void(restore_sigmask); ^^^ space > } > emit_ctxt_code (); > > @@ -3899,18 +3915,10 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, > GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, > SSDATA (tmp_file)); > > - /* Remove the old eln instead of copying the new one into it to get > - a new inode and prevent crashes in case the old one is currently > - loaded. */ > - if (!NILP (Ffile_exists_p (out_file))) > - Fdelete_file (out_file, Qnil); > - Frename_file (tmp_file, out_file, Qnil); > + CALL2I(comp--replace-output-file, out_file, tmp_file); ^^^ space > > if (!noninteractive) > - { > - pthread_sigmask (SIG_SETMASK, &oldset, 0); > - unblock_input (); > - } > + unbind_to(count, Qnil); > > return out_file; > } > @@ -3972,6 +3980,138 @@ helper_PSEUDOVECTOR_TYPEP_XUNTAG (Lisp_Object a, enum pvec_type code) > } > > > +/*********************************/ > +/* Disposal of compilation units */ > +/*********************************/ > + > +#ifdef WINDOWSNT > +#define OLD_ELN_SUFFIX_REGEXP build_string("\\.eln\\.old$") I think instead of $ \\' is more correct. > +static Lisp_Object all_loaded_comp_units; All hash table in this files are postfixed as _h > +struct delayed_comp_unit_disposal > +{ > + struct delayed_comp_unit_disposal * next; ^^^ no space here > + char * filename; ^^ likewise > +}; Why an ad-hoc C structure and not a simple cons? I think it would be simpler and safer to use just a lisp list here. Is it because we need to add during GC? If yes, comment :) > +struct delayed_comp_unit_disposal * delayed_comp_unit_disposal_list; ^^ likewise and the followings > + > +static Lisp_Object > +returnQnil (Lisp_Object arg) No camel case in function names. > +{ > + return Qnil; > +} I think each of the following functions really needs a comment line to explain the scope of each of them + one preamble comment to explain all the rename mechanism how is expected to work and the two datastructures involved. > +static void > +clean_comp_unit_directory (Lisp_Object filepath) > +{ > + if (NILP (filepath)) > + return; > + Lisp_Object files_in_dir; > + files_in_dir = internal_condition_case_4(Fdirectory_files, filepath, Qt, > + OLD_ELN_SUFFIX_REGEXP, Qnil, Qt, returnQnil); 80 columns > + FOR_EACH_TAIL(files_in_dir) > + { > + DeleteFile (SSDATA (XCAR (files_in_dir))); > + } > +} > + > +void clean_package_user_dir_of_old_comp_units (void) ^^^ new lines > +{ > + Lisp_Object package_user_dir = find_symbol_value (intern ("package-user-dir")); > + if (EQ(package_user_dir, Qunbound) || !STRINGP(package_user_dir)) > + return; > + > + clean_comp_unit_directory(package_user_dir); > +} > + > +#endif > + > +void dispose_comp_unit (struct Lisp_Native_Comp_Unit * comp_handle, bool delay) ^^^ likewise > +{ > + eassert (comp_handle->handle); > + dynlib_close (comp_handle->handle); > +#ifdef WINDOWSNT > + if (!delay) > + { > + Lisp_Object dirname = internal_condition_case_1(Ffile_name_directory, > + build_string (comp_handle->cfile), > + Qt, > + returnQnil); > + if (!NILP(dirname)) > + clean_comp_unit_directory (dirname); I think we need to comment here why when we dispose the compilation unit we try to clean the full directory. > + xfree (comp_handle->cfile); > + comp_handle->cfile = NULL; > + } > + else > + { > + struct delayed_comp_unit_disposal * head; > + head = xmalloc (sizeof (struct delayed_comp_unit_disposal)); > + head->next = delayed_comp_unit_disposal_list; > + head->filename = comp_handle->cfile; > + comp_handle->cfile = NULL; > + delayed_comp_unit_disposal_list = head; > + } > +#else > + xfree (comp_handle->file); > +#endif > +} Also, wasn't the plan to try to delete the file and in case of failure to put it in a list? Here when delay is true this goes directly in the list. Could you explain why and add comment? > +static void > +register_native_comp_unit (Lisp_Object comp_u) > +{ > +#ifdef WINDOWSNT > + static EMACS_UINT count; > + > + if (XFIXNUM(Fhash_table_count(all_loaded_comp_units)) >= MOST_POSITIVE_FIXNUM) > + return; > + > + while (!NILP(Fgethash(make_fixnum(count), all_loaded_comp_units, Qnil))) > + count = (count + 1) % MOST_POSITIVE_FIXNUM; Given you are doing all of this just to get a key (we'll not use) I think would be wise to just create the key using gensym. > + Fputhash(make_fixnum(count), comp_u, all_loaded_comp_units); > +#endif > +} > > +void dispose_all_remaining_comp_units (void) > +{ > +#ifdef WINDOWSNT > + struct Lisp_Hash_Table *h = XHASH_TABLE (all_loaded_comp_units); > + > + for (ptrdiff_t i = 0; i < HASH_TABLE_SIZE (h); ++i) > + { > + Lisp_Object k = HASH_KEY (h, i); > + if (!EQ (k, Qunbound)) > + { > + Lisp_Object val = HASH_VALUE (h, i); > + struct Lisp_Native_Comp_Unit * cu = XNATIVE_COMP_UNIT(val); > + dispose_comp_unit(cu, false); > + } > + } > +#endif > +} > + > +void finish_delayed_disposal_of_comp_units (void) > +{ > +#ifdef WINDOWSNT > + for (struct delayed_comp_unit_disposal * item = delayed_comp_unit_disposal_list; > + delayed_comp_unit_disposal_list; > + item = delayed_comp_unit_disposal_list) > + { > + delayed_comp_unit_disposal_list = item->next; > + Lisp_Object dirname > + = internal_condition_case_1 (Ffile_name_directory, > + build_string (item->filename), Qt, > + returnQnil); > + clean_comp_unit_directory (dirname); > + xfree(item->filename); > + xfree(item); > + } > +#endif > +} > + > + > /***********************************/ > /* Deferred compilation mechanism. */ > /***********************************/ > @@ -4192,6 +4332,12 @@ load_comp_unit (struct Lisp_Native_Comp_Unit *comp_u, bool loading_dump, > d_vec_len = XFIXNUM (Flength (comp_u->data_impure_vec)); > for (EMACS_INT i = 0; i < d_vec_len; i++) > data_imp_relocs[i] = AREF (comp_u->data_impure_vec, i); > + > + /* If we register them while dumping we will get some entries in > + the hash table that will be duplicated when pdumper calls > + load_comp_unit. */ > + if (!will_dump_p()) > + register_native_comp_unit (comp_u_lisp_obj); > } > > if (!loading_dump) > @@ -4349,6 +4495,9 @@ DEFUN ("native-elisp-load", Fnative_elisp_load, Snative_elisp_load, 1, 2, 0, > if (!comp_u->handle) > xsignal2 (Qnative_lisp_load_failed, file, build_string (dynlib_error ())); > comp_u->file = file; > +#ifdef WINDOWSNT > + comp_u->cfile = xlispstrdup(file); > +#endif > comp_u->data_vec = Qnil; > comp_u->lambda_gc_guard = CALLN (Fmake_hash_table, QCtest, Qeq); > comp_u->lambda_c_name_idx_h = CALLN (Fmake_hash_table, QCtest, Qequal); > @@ -4497,6 +4646,11 @@ syms_of_comp (void) > staticpro (&delayed_sources); > delayed_sources = Qnil; > > +#ifdef WINDOWSNT > + staticpro (&all_loaded_comp_units); > + all_loaded_comp_units = CALLN(Fmake_hash_table, QCweakness, Qvalue); > +#endif > + > DEFVAR_LISP ("comp-ctxt", Vcomp_ctxt, > doc: /* The compiler context. */); > Vcomp_ctxt = Qnil; > diff --git a/src/comp.h b/src/comp.h > index 36e7cdf441..0b790fc7cb 100644 > --- a/src/comp.h > +++ b/src/comp.h > @@ -52,7 +52,15 @@ struct Lisp_Native_Comp_Unit > /* STUFFS WE DO NOT DUMP!! */ > Lisp_Object *data_imp_relocs; > bool loaded_once; > + > dynlib_handle_ptr handle; > +#ifdef WINDOWSNT > + /* We need to store a copy of the original file name in memory that > + is not subject to GC because the function to dispose native > + compilation units is called by the GC. By that time the `file' > + string may have been sweeped. */ > + char * cfile; > +#endif > }; > > #ifdef HAVE_NATIVE_COMP > @@ -83,6 +91,14 @@ extern void syms_of_comp (void); > > extern void maybe_defer_native_compilation (Lisp_Object function_name, > Lisp_Object definition); > + > +extern void dispose_comp_unit (struct Lisp_Native_Comp_Unit * > comp_unit, bool delay); > + > +extern void finish_delayed_disposal_of_comp_units (void); > + > +extern void dispose_all_remaining_comp_units (void); > + > +extern void clean_package_user_dir_of_old_comp_units (void); > #else > > static inline void > @@ -92,6 +108,17 @@ maybe_defer_native_compilation (Lisp_Object function_name, > > extern void syms_of_comp (void); > > +static inline void dispose_comp_unit (struct Lisp_Native_Comp_Unit * comp_handle) Newline after ret type for this and the following definitions. > +{ > + emacs_abort(); > +} emacs_abort is still not declared here so it does not compile. Maybe we can just put an eassert (false). > +static inline void dispose_all_remaining_comp_units (void) > +{} > + > +static inline void clean_package_user_dir_of_old_comp_units (void) > +{} > + Thanks Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 19:43:31 2020 Received: (at 41242) by debbugs.gnu.org; 23 May 2020 23:43:31 +0000 Received: from localhost ([127.0.0.1]:36047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcdnc-0000nX-AA for submit@debbugs.gnu.org; Sat, 23 May 2020 19:43:31 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:34549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcdnY-0000nH-0G for 41242@debbugs.gnu.org; Sat, 23 May 2020 19:43:27 -0400 Received: by mail-ot1-f48.google.com with SMTP id b18so11238680oti.1 for <41242@debbugs.gnu.org>; Sat, 23 May 2020 16:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g3v5Wqyas3dSviCiKF0yVfBn9W6mHvfUH3KfnbCBuw8=; b=G9mlr1+Gs4FKS4n4HtEwb9Fz2i4Y1y1LNTeXcsJfCz+Bwb4JQe2jjC8GKxl6L+9b1h YAlW+Tl3PUNgQxh3QfrPlwpXKyvBGgvKTxdRWHYrqhedRvNArut4vmw4xTW9dcrbXHBt 4bgWayhFY2HrCasu01c67MJrins1xeoAZQlteBaKtPZGZJinHhWsmJEuxTyjrAi1Krzj DVZNnHASyldYehBhgj9rQBc2Ab9ofQJ5kB9c6id0AWcUlDbiIoHe2LEsXDL5hUC8oIBt ykucPBEst7Rvr8N2AbTIZNOYBzuD8UY/ntXhuYZ8AxubqaaApzZ6PCIG8o6pG7My2ipo 6EUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g3v5Wqyas3dSviCiKF0yVfBn9W6mHvfUH3KfnbCBuw8=; b=lJDtdq8Qwa7wG4HTNPYdcE8ydvDslL8pq+8kyqNMmaRQ/HwT0NXo3PHHsHjvZ5bOIw 7wlxyS3zabWZjo+e0lzRh6dSjMwUVnHe+hzX0KWP6lbhaDvS3MwpOkUN6xneCo1X0QIc QJ71wWfcdlnSlNh/ZQvDCnrvymo0x9DvyhXyhZ0EeZctddt1DR+plsLDI/dF7la/4LV2 fMQzTgrA7dFh0g0WfSEfK7tnGmiGaFOoGuT7B/7wFWYMEEgGqqFfgTEJaxnkFANRCByo pxQLkQDC8iF14e2V1cPW02eu+kvcrRDx0d7peRfZ291ZLGXIM+48fvP2nE2JEkWj1AQP 8O8Q== X-Gm-Message-State: AOAM531apbCp/YZtWM2iicrRZq18o/LPCDTdZ3DS2ouBFaNstUdj8YZk x0nFnE4VIOMubsX2Mr1BpyTMvXAzMp49aNV0ruI= X-Google-Smtp-Source: ABdhPJz5lm2o8D8k811eNKSDbXdGkJ7siskUhgA3ra1nn/BQ7QQZUQsYdd9McS/fX4fs92VolNcvSgf3ES+4KlZKYj0= X-Received: by 2002:a9d:191:: with SMTP id e17mr15501262ote.193.1590277397966; Sat, 23 May 2020 16:43:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 23 May 2020 20:43:06 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... To: Andrea Corallo Content-Type: multipart/alternative; boundary="00000000000066748305a6594ffb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --00000000000066748305a6594ffb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrea, Thanks for the feedback. > Please review all the GNU code-style of this diff. I've annotated some > to be fixed but there are quite a number more of fixes of the same kind > to be done. This is such a pain, I sometimes forget to change Emacs to GNU style and sometimes I'll write GNU style at work. > > +(defun comp--replace-output-file (outfile tmpfile) > > + "Replace OUTFILE with TMPFILE taking the necessary steps when > > +dealing with shared libraries that may be loaded into Emacs" > > + (cond ((eq 'windows-nt system-type) > > + (ignore-errors (delete-file outfile)) > > + (let ((retry t)) > > + (while retry > > + (setf retry nil) > > + (condition-case _ > > + (progn > > + ;; outfile maybe recreated by another Emacs in > > + ;; between the following two rename-file calls > > + (if (file-exists-p outfile) > > + (rename-file outfile (make-temp-file-internal > > + (file-name-sans-extension outfile) > > + nil ".eln.old" nil) > Isn't better to just add .old? So we will have cases of foo.eln.old.old > instead of foo.eln.old.eln.old ? We can't do that because foo.eln.old might exist already. This code tries t= o rename an existing foo.eln to fooXXXXXX.eln.old where XXXXXX are random. We should never try to rename fooXXXXXX.eln.old if it already exists. > > +(defun package--delete-directory (dir) > > + "Delete DIR recursively. > > +In Windows move .eln and .eln.old files that can not be deleted to `package-user-dir'." > 80 column lines limit. I think also this should be transparent when > native-comp-available-p say native comp is not available (for now > compiler and load machinery are bundled). We might be trying to delete an .eln file that another Emacs instance has loaded. I know it sounds kind of strange, but if that is not the case then `package--delete-directory` will just call `delete-directory`. > I think would be good to destructure err using something like > cl-destructuring-bind or pcase or even just using a let + some naming to > make this more readable. Good idea. > > @@ -6117,6 +6116,8 @@ garbage_collect (void) > > if (tot_after < tot_before) > > malloc_probe (min (tot_before - tot_after, SIZE_MAX)); > > } > > + > > + finish_delayed_disposal_of_comp_units (); > Could you describe why we need to call this each garbage collection? > Isn't sufficient to do it when emacs is exiting? I thought it was cleaner to delete *.eln.old ASAP. It would make it necessary to store the original files in a list, anyway. > That said this is unclear to me because in comp--compile-ctxt-to-file > oldset is automatic and shadows this static, so I think we'll save in > the the automatic and later we just restore the (always zeroed) static > one. You are right. I'll fix it. > +struct delayed_comp_unit_disposal > +{ > + struct delayed_comp_unit_disposal * next; ^^^ no space here > + char * filename; ^^ likewise > +}; > Why an ad-hoc C structure and not a simple cons? I think it would be > simpler and safer to use just a lisp list here. Is it because we need > to add during GC? If yes, comment :) Exactly. Since filename needs to be a C string, I figured that using a C struct would be simpler that trying to wrap the C string in a Lisp object. > I think each of the following functions really needs a comment line to > explain the scope of each of them + one preamble comment to explain all > the rename mechanism how is expected to work and the two datastructures > involved. Sure. > +{ > + eassert (comp_handle->handle); > + dynlib_close (comp_handle->handle); > +#ifdef WINDOWSNT > + if (!delay) > + { > + Lisp_Object dirname =3D internal_condition_case_1(Ffile_name_directory, > + build_string (comp_handle->cfile), > + Qt, > + returnQnil); > + if (!NILP(dirname)) > + clean_comp_unit_directory (dirname); > I think we need to comment here why when we dispose the compilation unit > we try to clean the full directory. This is because ideally we'd try to delete fooXXXXXX.eln.old if we are disposing the "foo" compilation unit and the file has been renamed. It turns out that there is no simple way to figure out the current name of a loaded module in Windows. GetModuleFileName returns the filename it had at the time we loaded it. Deleting all the *.eln.old in the directory is the (simple) workaround. > + xfree (comp_handle->cfile); > + comp_handle->cfile =3D NULL; > + } > + else > + { > + struct delayed_comp_unit_disposal * head; > + head =3D xmalloc (sizeof (struct delayed_comp_unit_disposal)); > + head->next =3D delayed_comp_unit_disposal_list; > + head->filename =3D comp_handle->cfile; > + comp_handle->cfile =3D NULL; > + delayed_comp_unit_disposal_list =3D head; > + } > +#else > + xfree (comp_handle->file); > +#endif > +} > Also, wasn't the plan to try to delete the file and in case of failure > to put it in a list? Here when delay is true this goes directly in the > list. Could you explain why and add comment? There are two reasons: We don't have a simple way of getting the current name of the module (see above). Deleting all the files in the directory is implemented using Fdirectory_files, that allocates Lisp objects, and doing that in the middle of a GC sweep is cause of crashes (already tried). > Given you are doing all of this just to get a key (we'll not use) I > think would be wise to just create the key using gensym. Great! Nicolas. El s=C3=A1b., 23 may. 2020 a las 19:58, Andrea Corallo () esc= ribi=C3=B3: > Hi Nicolas, > > following some comments on - Improve handling of native compilation > etc. > > Please review all the GNU code-style of this diff. I've annotated some > to be fixed but there are quite a number more of fixes of the same kind > to be done. > > > When closing emacs will inspect all directories from which it loaded > > native compilation units. If it finds a ".eln.old" file it will try to > > delete it, if it fails that means that another Emacs instance is using > it. > > > > When compiling a file we rename the file that was in the output path > > in case it has been loaded into another Emacs instance. > > > > When deleting a package we move any ".eln" or ".eln.old" files in the > > package folder that we can't delete to `package-user-dir`. Emacs will > > check that directory when closing and delete them. > > > > * lisp/emacs-lisp/comp.el (comp--replace-output-file): Function called > > from C code to finish the compilation process. It performs renaming of > > the old file if necessary. > > * lisp/emacs-lisp/package.el (package--delete-directory): Function to > > delete a package directory. It moves native compilation units that it > > can't delete to `package-user-dir'. > > * src/alloc.c (cleanup_vector): Call dispose_comp_unit(). > > (garbage_collect): Call finish_delayed_disposal_of_comp_units(). > > * src/comp.c: Restore the signal mask using unwind-protect. Store > > loaded native compilation units in a hash table for disposal on > > close. Store filenames of native compilation units GC'd in a linked > > list to finish their disposal when the GC is over. > > Please annotate in the changelog the new functions ex: > finish_delayed_disposal_of_comp_units, dispose_all_remaining_comp_units, > register_native_comp_unit are missing. > > > * src/comp.h: Introduce cfile member in Lisp_Native_Comp_Unit. > > Add declarations of functions that: clean directories of unused native > > compilation units, handle disposal of native compilation units. > > * src/emacs.c (kill-emacs): Dispose all remaining compilation units > > right right before calling exit(). > > * src/eval.c (internal_condition_case_3, internal_condition_case_4): > > Add functions. > > * src/lisp.h (internal_condition_case_3, internal_condition_case_4): > > Add functions. > > * src/pdumper.c (dump_do_dump_relocation): Set cfile to a copy of the > > Lisp string specifying the file path. > > > diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el > > index 012baf2560..1fb4cd98c0 100644 > > --- a/lisp/emacs-lisp/comp.el > > +++ b/lisp/emacs-lisp/comp.el > > @@ -2183,6 +2183,31 @@ comp-hint-cons > > > > ;; Some entry point support code. > > > > +(defun comp--replace-output-file (outfile tmpfile) > > + "Replace OUTFILE with TMPFILE taking the necessary steps when > > +dealing with shared libraries that may be loaded into Emacs" > > + (cond ((eq 'windows-nt system-type) > > + (ignore-errors (delete-file outfile)) > > + (let ((retry t)) > > + (while retry > > + (setf retry nil) > > + (condition-case _ > > + (progn > > + ;; outfile maybe recreated by another Emacs in > > + ;; between the following two rename-file calls > > + (if (file-exists-p outfile) > > + (rename-file outfile (make-temp-file-internal > > + (file-name-sans-extension > outfile) > > + nil ".eln.old" nil) > > Isn't better to just add .old? So we will have cases of foo.eln.old.old > instead of foo.eln.old.eln.old ? > > > + t)) > > + (rename-file tmpfile outfile nil)) > > + (file-already-exists (setf retry t)))))) > > + ;; Remove the old eln instead of copying the new one into it > > + ;; to get a new inode and prevent crashes in case the old one > > + ;; is currently loaded. > > + (t (delete-file outfile) > > + (rename-file tmpfile outfile)))) > > + > > (defvar comp-files-queue () > > "List of Elisp files to be compiled.") > > > > > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > > index 95659840ad..c1c54b3c9a 100644 > > --- a/lisp/emacs-lisp/package.el > > +++ b/lisp/emacs-lisp/package.el > > @@ -2184,6 +2184,31 @@ If some packages are not installed propose to > install them." > > (equal (cadr (assq (package-desc-name pkg) package-alist)) > > pkg)) > > > > +(defun package--delete-directory (dir) > > + "Delete DIR recursively. > > +In Windows move .eln and .eln.old files that can not be deleted to > `package-user-dir'." > > 80 column lines limit. I think also this should be transparent when > native-comp-available-p say native comp is not available (for now > compiler and load machinery are bundled). > > > + (cond ((eq 'windows-nt system-type) > > + (let ((retry t)) > > + (while retry > > + (setf retry nil) > > + (condition-case err > > + (delete-directory dir t) > > + (file-error > > + (if (and (string=3D "Removing old name" (cadr err)) > > + (string=3D "Permission denied" (caddr err)) > > + (or (string-suffix-p ".eln" (cadddr err)) > > + (string-suffix-p ".eln.old" (cadddr err))= )) > > I think would be good to destructure err using something like > cl-destructuring-bind or pcase or even just using a let + some naming to > make this more readable. > > > + (progn > > + (rename-file (cadddr err) > > + (make-temp-file-internal > > + (concat package-user-dir > > + (file-name-base (cadddr > err))) > > + nil ".eln.old" nil) > > + t) > > + (setf retry t)) > > + (signal (car err) (cdr err)))))))) > > + (t (delete-directory dir t)))) > > + > > (defun package-delete (pkg-desc &optional force nosave) > > "Delete package PKG-DESC. > > > > @@ -2236,7 +2261,7 @@ If NOSAVE is non-nil, the package is not removed > from > > (package-desc-name pkg-used-elsewhere-by))) > > (t > > (add-hook 'post-command-hook #'package-menu--post-refresh) > > - (delete-directory dir t) > > + (package--delete-directory dir) > > ;; Remove NAME-VERSION.signed and NAME-readme.txt files. > > ;; > > ;; NAME-readme.txt files are no longer created, but they > > diff --git a/src/alloc.c b/src/alloc.c > > index d6ba4d9790..420168ec4d 100644 > > --- a/src/alloc.c > > +++ b/src/alloc.c > > @@ -3119,8 +3119,7 @@ cleanup_vector (struct Lisp_Vector *vector) > > { > > struct Lisp_Native_Comp_Unit *cu =3D > > PSEUDOVEC_STRUCT (vector, Lisp_Native_Comp_Unit); > > - eassert (cu->handle); > > - dynlib_close (cu->handle); > > + dispose_comp_unit (cu, true); > > } > > } > > > > @@ -6117,6 +6116,8 @@ garbage_collect (void) > > if (tot_after < tot_before) > > malloc_probe (min (tot_before - tot_after, SIZE_MAX)); > > } > > + > > + finish_delayed_disposal_of_comp_units (); > > Could you describe why we need to call this each garbage collection? > Isn't sufficient to do it when emacs is exiting? > > > } > > > > DEFUN ("garbage-collect", Fgarbage_collect, Sgarbage_collect, 0, 0, ""= , > > diff --git a/src/comp.c b/src/comp.c > > index dd45599cc4..77c3006c56 100644 > > --- a/src/comp.c > > +++ b/src/comp.c > > @@ -413,6 +413,10 @@ load_gccjit_if_necessary (bool mandatory) > > #define CALL1I(fun, arg) \ > > CALLN (Ffuncall, intern_c_string (STR (fun)), arg) > > > > +/* Like call2 but stringify and intern. */ > > +#define CALL2I(fun, arg1, arg2) \ > > + CALLN (Ffuncall, intern_c_string (STR (fun)), arg1, arg2) > > + > > #define DECL_BLOCK(name, func) \ > > gcc_jit_block *(name) =3D \ > > gcc_jit_function_new_block ((func), STR (name)) > > @@ -3828,6 +3832,14 @@ DEFUN ("comp--release-ctxt", Fcomp__release_ctxt= , > Scomp__release_ctxt, > > return Qt; > > } > > > > +sigset_t oldset; > > I think we have all static data at the top. > > That said this is unclear to me because in comp--compile-ctxt-to-file > oldset is automatic and shadows this static, so I think we'll save in > the the automatic and later we just restore the (always zeroed) static > one. > > > +static void restore_sigmask(void) > ^^^ > space > > +{ > > + pthread_sigmask (SIG_SETMASK, &oldset, 0); > > + unblock_input (); > > +} > > + > > DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file, > > Scomp__compile_ctxt_to_file, > > 1, 1, 0, > > @@ -3849,6 +3861,8 @@ DEFUN ("comp--compile-ctxt-to-file", > Fcomp__compile_ctxt_to_file, > > CALL1I (comp-data-container-idx, CALL1I (comp-ctxt-d-ephemeral, > Vcomp_ctxt)); > > > > sigset_t oldset; > > + ptrdiff_t count; > > + > > if (!noninteractive) > > { > > sigset_t blocked; > > @@ -3861,6 +3875,8 @@ DEFUN ("comp--compile-ctxt-to-file", > Fcomp__compile_ctxt_to_file, > > sigaddset (&blocked, SIGIO); > > #endif > > pthread_sigmask (SIG_BLOCK, &blocked, &oldset); > > + count =3D SPECPDL_INDEX (); > > + record_unwind_protect_void(restore_sigmask); > ^^^ > space > > > } > > emit_ctxt_code (); > > > > @@ -3899,18 +3915,10 @@ DEFUN ("comp--compile-ctxt-to-file", > Fcomp__compile_ctxt_to_file, > > GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, > > SSDATA (tmp_file)); > > > > - /* Remove the old eln instead of copying the new one into it to get > > - a new inode and prevent crashes in case the old one is currently > > - loaded. */ > > - if (!NILP (Ffile_exists_p (out_file))) > > - Fdelete_file (out_file, Qnil); > > - Frename_file (tmp_file, out_file, Qnil); > > + CALL2I(comp--replace-output-file, out_file, tmp_file); > ^^^ > space > > > > if (!noninteractive) > > - { > > - pthread_sigmask (SIG_SETMASK, &oldset, 0); > > - unblock_input (); > > - } > > + unbind_to(count, Qnil); > > > > return out_file; > > } > > @@ -3972,6 +3980,138 @@ helper_PSEUDOVECTOR_TYPEP_XUNTAG (Lisp_Object a= , > enum pvec_type code) > > } > > > > > > +/*********************************/ > > +/* Disposal of compilation units */ > > +/*********************************/ > > + > > +#ifdef WINDOWSNT > > +#define OLD_ELN_SUFFIX_REGEXP build_string("\\.eln\\.old$") > > I think instead of $ \\' is more correct. > > > +static Lisp_Object all_loaded_comp_units; > > All hash table in this files are postfixed as _h > > > +struct delayed_comp_unit_disposal > > +{ > > + struct delayed_comp_unit_disposal * next; > ^^^ > no space here > > + char * filename; > ^^ > likewise > > +}; > > Why an ad-hoc C structure and not a simple cons? I think it would be > simpler and safer to use just a lisp list here. Is it because we need > to add during GC? If yes, comment :) > > > +struct delayed_comp_unit_disposal * delayed_comp_unit_disposal_list; > ^^ > likewise and the followings > > + > > +static Lisp_Object > > +returnQnil (Lisp_Object arg) > > No camel case in function names. > > > +{ > > + return Qnil; > > +} > > I think each of the following functions really needs a comment line to > explain the scope of each of them + one preamble comment to explain all > the rename mechanism how is expected to work and the two datastructures > involved. > > > +static void > > +clean_comp_unit_directory (Lisp_Object filepath) > > +{ > > + if (NILP (filepath)) > > + return; > > + Lisp_Object files_in_dir; > > + files_in_dir =3D internal_condition_case_4(Fdirectory_files, filepat= h, > Qt, > > + OLD_ELN_SUFFIX_REGEXP, Qnil= , > Qt, returnQnil); > > 80 columns > > > + FOR_EACH_TAIL(files_in_dir) > > + { > > + DeleteFile (SSDATA (XCAR (files_in_dir))); > > + } > > +} > > + > > +void clean_package_user_dir_of_old_comp_units (void) > ^^^ > new lines > > +{ > > + Lisp_Object package_user_dir =3D find_symbol_value (intern > ("package-user-dir")); > > + if (EQ(package_user_dir, Qunbound) || !STRINGP(package_user_dir)) > > + return; > > + > > + clean_comp_unit_directory(package_user_dir); > > +} > > + > > +#endif > > + > > +void dispose_comp_unit (struct Lisp_Native_Comp_Unit * comp_handle, > bool delay) > ^^^ > likewise > > +{ > > + eassert (comp_handle->handle); > > + dynlib_close (comp_handle->handle); > > +#ifdef WINDOWSNT > > + if (!delay) > > + { > > + Lisp_Object dirname =3D > internal_condition_case_1(Ffile_name_directory, > > + build_string > (comp_handle->cfile), > > + Qt, > > + returnQnil); > > + if (!NILP(dirname)) > > + clean_comp_unit_directory (dirname); > > I think we need to comment here why when we dispose the compilation unit > we try to clean the full directory. > > > + xfree (comp_handle->cfile); > > + comp_handle->cfile =3D NULL; > > + } > > + else > > + { > > + struct delayed_comp_unit_disposal * head; > > + head =3D xmalloc (sizeof (struct delayed_comp_unit_disposal)); > > + head->next =3D delayed_comp_unit_disposal_list; > > + head->filename =3D comp_handle->cfile; > > + comp_handle->cfile =3D NULL; > > + delayed_comp_unit_disposal_list =3D head; > > + } > > +#else > > + xfree (comp_handle->file); > > +#endif > > +} > > Also, wasn't the plan to try to delete the file and in case of failure > to put it in a list? Here when delay is true this goes directly in the > list. Could you explain why and add comment? > > > +static void > > +register_native_comp_unit (Lisp_Object comp_u) > > +{ > > +#ifdef WINDOWSNT > > + static EMACS_UINT count; > > + > > + if (XFIXNUM(Fhash_table_count(all_loaded_comp_units)) >=3D > MOST_POSITIVE_FIXNUM) > > + return; > > + > > + while (!NILP(Fgethash(make_fixnum(count), all_loaded_comp_units, > Qnil))) > > + count =3D (count + 1) % MOST_POSITIVE_FIXNUM; > > Given you are doing all of this just to get a key (we'll not use) I > think would be wise to just create the key using gensym. > > > + Fputhash(make_fixnum(count), comp_u, all_loaded_comp_units); > > +#endif > > +} > > > > +void dispose_all_remaining_comp_units (void) > > +{ > > +#ifdef WINDOWSNT > > + struct Lisp_Hash_Table *h =3D XHASH_TABLE (all_loaded_comp_units); > > + > > + for (ptrdiff_t i =3D 0; i < HASH_TABLE_SIZE (h); ++i) > > + { > > + Lisp_Object k =3D HASH_KEY (h, i); > > + if (!EQ (k, Qunbound)) > > + { > > + Lisp_Object val =3D HASH_VALUE (h, i); > > + struct Lisp_Native_Comp_Unit * cu =3D XNATIVE_COMP_UNIT(val)= ; > > + dispose_comp_unit(cu, false); > > + } > > + } > > +#endif > > +} > > + > > > > > +void finish_delayed_disposal_of_comp_units (void) > > +{ > > +#ifdef WINDOWSNT > > + for (struct delayed_comp_unit_disposal * item =3D > delayed_comp_unit_disposal_list; > > + delayed_comp_unit_disposal_list; > > + item =3D delayed_comp_unit_disposal_list) > > + { > > + delayed_comp_unit_disposal_list =3D item->next; > > + Lisp_Object dirname > > + =3D internal_condition_case_1 (Ffile_name_directory, > > + build_string (item->filename), Qt= , > > + returnQnil); > > + clean_comp_unit_directory (dirname); > > + xfree(item->filename); > > + xfree(item); > > + } > > +#endif > > +} > > + > > + > > /***********************************/ > > /* Deferred compilation mechanism. */ > > /***********************************/ > > @@ -4192,6 +4332,12 @@ load_comp_unit (struct Lisp_Native_Comp_Unit > *comp_u, bool loading_dump, > > d_vec_len =3D XFIXNUM (Flength (comp_u->data_impure_vec)); > > for (EMACS_INT i =3D 0; i < d_vec_len; i++) > > data_imp_relocs[i] =3D AREF (comp_u->data_impure_vec, i); > > + > > + /* If we register them while dumping we will get some entries in > > + the hash table that will be duplicated when pdumper calls > > + load_comp_unit. */ > > + if (!will_dump_p()) > > + register_native_comp_unit (comp_u_lisp_obj); > > } > > > > if (!loading_dump) > > @@ -4349,6 +4495,9 @@ DEFUN ("native-elisp-load", Fnative_elisp_load, > Snative_elisp_load, 1, 2, 0, > > if (!comp_u->handle) > > xsignal2 (Qnative_lisp_load_failed, file, build_string > (dynlib_error ())); > > comp_u->file =3D file; > > +#ifdef WINDOWSNT > > + comp_u->cfile =3D xlispstrdup(file); > > +#endif > > comp_u->data_vec =3D Qnil; > > comp_u->lambda_gc_guard =3D CALLN (Fmake_hash_table, QCtest, Qeq); > > comp_u->lambda_c_name_idx_h =3D CALLN (Fmake_hash_table, QCtest, > Qequal); > > @@ -4497,6 +4646,11 @@ syms_of_comp (void) > > staticpro (&delayed_sources); > > delayed_sources =3D Qnil; > > > > +#ifdef WINDOWSNT > > + staticpro (&all_loaded_comp_units); > > + all_loaded_comp_units =3D CALLN(Fmake_hash_table, QCweakness, Qvalue= ); > > +#endif > > + > > DEFVAR_LISP ("comp-ctxt", Vcomp_ctxt, > > doc: /* The compiler context. */); > > Vcomp_ctxt =3D Qnil; > > diff --git a/src/comp.h b/src/comp.h > > index 36e7cdf441..0b790fc7cb 100644 > > --- a/src/comp.h > > +++ b/src/comp.h > > @@ -52,7 +52,15 @@ struct Lisp_Native_Comp_Unit > > /* STUFFS WE DO NOT DUMP!! */ > > Lisp_Object *data_imp_relocs; > > bool loaded_once; > > + > > dynlib_handle_ptr handle; > > +#ifdef WINDOWSNT > > + /* We need to store a copy of the original file name in memory that > > + is not subject to GC because the function to dispose native > > + compilation units is called by the GC. By that time the `file' > > + string may have been sweeped. */ > > + char * cfile; > > +#endif > > }; > > > > #ifdef HAVE_NATIVE_COMP > > @@ -83,6 +91,14 @@ extern void syms_of_comp (void); > > > > extern void maybe_defer_native_compilation (Lisp_Object function_name, > > Lisp_Object definition); > > + > > +extern void dispose_comp_unit (struct Lisp_Native_Comp_Unit * > > comp_unit, bool delay); > > + > > +extern void finish_delayed_disposal_of_comp_units (void); > > + > > +extern void dispose_all_remaining_comp_units (void); > > + > > +extern void clean_package_user_dir_of_old_comp_units (void); > > #else > > > > static inline void > > @@ -92,6 +108,17 @@ maybe_defer_native_compilation (Lisp_Object > function_name, > > > > extern void syms_of_comp (void); > > > > +static inline void dispose_comp_unit (struct Lisp_Native_Comp_Unit * > comp_handle) > > Newline after ret type for this and the following definitions. > > > +{ > > + emacs_abort(); > > +} > > emacs_abort is still not declared here so it does not compile. Maybe we > can just put an eassert (false). > > > +static inline void dispose_all_remaining_comp_units (void) > > +{} > > + > > +static inline void clean_package_user_dir_of_old_comp_units (void) > > +{} > > + > > > Thanks > > Andrea > > -- > akrl@sdf.org > --00000000000066748305a6594ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrea,

Thanks for the fe= edback.

> Please review all the GNU code-style of this diff= .=C2=A0 I've annotated some
> to be fixed but there are quite a n= umber more of fixes of the same kind
> to be done.

This is suc= h a pain, I sometimes forget to change Emacs to GNU style and
sometimes = I'll write GNU style at work.

> > +(defun comp--replace-ou= tput-file (outfile tmpfile)
> > + =C2=A0"Replace OUTFILE with= TMPFILE taking the necessary steps when
> > +dealing with shared = libraries that may be loaded into Emacs"
> > + =C2=A0(cond ((= eq 'windows-nt system-type)
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 = (ignore-errors (delete-file outfile))
> > + =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (let ((retry t))
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= while retry
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setf = retry nil)
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (condit= ion-case _
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (progn
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ;; outfile maybe recreated by another Emacs in
> &g= t; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; betw= een the following two rename-file calls
> > + =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if (file-exists-p outfile)
&= gt; > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (rename-file outfile (make-temp-file-internal
> > + = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (file-name-sans-extension outfile)
> > + =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nil ".e= ln.old" nil)

> Isn't better to just add .old? So we will= have cases of foo.eln.old.old
> instead of foo.eln.old.eln.old ?
=
We can't do that because foo.eln.old might exist already. This code= tries to
rename an existing foo.eln to fooXXXXXX.eln.old where XXXXXX a= re random. We
should never try to rename fooXXXXXX.eln.old if it already= exists.

> > +(defun package--delete-directory (dir)
> &= gt; + =C2=A0"Delete DIR recursively.
> > +In Windows move .el= n and .eln.old files that can not be deleted to `package-user-dir'.&quo= t;

> 80 column lines limit.=C2=A0 I think also this should be tra= nsparent when
> native-comp-available-p say native comp is not availa= ble (for now
> compiler and load machinery are bundled).

We mi= ght be trying to delete an .eln file that another Emacs instance has
loa= ded. I know it sounds kind of strange, but if that is not the case then
= `package--delete-directory` will just call `delete-directory`.

> = I think would be good to destructure err using something like
> cl-de= structuring-bind or pcase or even just using a let + some naming to
>= make this more readable.

Good idea.

> > @@ -6117,6 +61= 16,8 @@ garbage_collect (void)
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (= tot_after < tot_before)
> > =C2=A0 =C2=A0 =C2=A0 malloc_probe (= min (tot_before - tot_after, SIZE_MAX));
> > =C2=A0 =C2=A0 =C2=A0}=
> > +
> > + =C2=A0finish_delayed_disposal_of_comp_units = ();

> Could you describe why we need to call this each garbage co= llection?
> Isn't sufficient to do it when emacs is exiting?
<= br>I thought it was cleaner to delete *.eln.old ASAP. It would make it nece= ssary to
store the original files in a list, anyway.

> That sa= id this is unclear to me because in comp--compile-ctxt-to-file
> olds= et is automatic and shadows this static, so I think we'll save in
&g= t; the the automatic and later we just restore the (always zeroed) static> one.

You are right. I'll fix it.

> +struct del= ayed_comp_unit_disposal
> +{
> + =C2=A0struct delayed_comp_unit= _disposal * next;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0no space here
> + =C2=A0char * filename;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 likewise
> +};=

> Why an ad-hoc C structure and not a simple cons?=C2=A0 I think= it would be
> simpler and safer to use just a lisp list here.=C2=A0 = Is it because we need
> to add during GC?=C2=A0 If yes, comment :)
Exactly. Since filename needs to be a C string, I figured that using a= C struct
would be simpler that trying to wrap the C string in a Lisp ob= ject.

> I think each of the following functions really needs a co= mment line to
> explain the scope of each of them + one preamble comm= ent to explain all
> the rename mechanism how is expected to work and= the two datastructures
> involved.

Sure.

> +{
&g= t; + =C2=A0eassert (comp_handle->handle);
> + =C2=A0dynlib_close (= comp_handle->handle);
> +#ifdef WINDOWSNT
> + =C2=A0if (!del= ay)
> + =C2=A0 =C2=A0{
> + =C2=A0 =C2=A0 =C2=A0Lisp_Object dirn= ame =3D internal_condition_case_1(Ffile_name_directory,
> + =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build_string (comp_handle->cfile),
= > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Qt,
> + =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0returnQnil);
> + =C2=A0 =C2=A0 =C2=A0if (!= NILP(dirname))
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0clean_comp_unit_directo= ry (dirname);

> I think we need to comment here why when we dispo= se the compilation unit
> we try to clean the full directory.

= This is because ideally we'd try to delete fooXXXXXX.eln.old if we are = disposing
the "foo" compilation unit and the file has been ren= amed. It turns out that
there is no simple way to figure out the current= name of a loaded module in
Windows. GetModuleFileName returns the filen= ame it had at the time we loaded it.
Deleting all the *.eln.old in the d= irectory is the (simple) workaround.

> + =C2=A0 =C2=A0 =C2=A0xfre= e (comp_handle->cfile);
> + =C2=A0 =C2=A0 =C2=A0comp_handle->cf= ile =3D NULL;
> + =C2=A0 =C2=A0}
> + =C2=A0else
> + =C2= =A0 =C2=A0{
> + =C2=A0 =C2=A0 =C2=A0struct delayed_comp_unit_disposal= * head;
> + =C2=A0 =C2=A0 =C2=A0head =3D xmalloc (sizeof (struct del= ayed_comp_unit_disposal));
> + =C2=A0 =C2=A0 =C2=A0head->next =3D = delayed_comp_unit_disposal_list;
> + =C2=A0 =C2=A0 =C2=A0head->fil= ename =3D comp_handle->cfile;
> + =C2=A0 =C2=A0 =C2=A0comp_handle-= >cfile =3D NULL;
> + =C2=A0 =C2=A0 =C2=A0delayed_comp_unit_disposa= l_list =3D head;
> + =C2=A0 =C2=A0}
> +#else
> + =C2=A0xf= ree (comp_handle->file);
> +#endif
> +}

> Also, wa= sn't the plan to try to delete the file and in case of failure
> = to put it in a list?=C2=A0 Here when delay is true this goes directly in th= e
> list.=C2=A0 Could you explain why and add comment?

There a= re two reasons:

We don't have a simple way of getting the curren= t name of the module (see
above).

Deleting all the files in the d= irectory is implemented using Fdirectory_files,
that allocates Lisp obje= cts, and doing that in the middle of a GC sweep is cause
of crashes (alr= eady tried).

> Given you are doing all of this just to get a key = (we'll not use) I
> think would be wise to just create the key us= ing gensym.

Great!

Nicolas.

El s=C3=A1b., 23 may. 2020 a l= as 19:58, Andrea Corallo (<akrl@sdf.org<= /a>>) escribi=C3=B3:
Hi Nicolas,

following some comments on - Improve handling of native compilation
etc.

Please review all the GNU code-style of this diff.=C2=A0 I've annotated= some
to be fixed but there are quite a number more of fixes of the same kind
to be done.

> When closing emacs will inspect all directories from which it loaded > native compilation units. If it finds a ".eln.old" file it w= ill try to
> delete it, if it fails that means that another Emacs instance is using= it.
>
> When compiling a file we rename the file that was in the output path > in case it has been loaded into another Emacs instance.
>
> When deleting a package we move any ".eln" or ".eln.old= " files in the
> package folder that we can't delete to `package-user-dir`. Emacs w= ill
> check that directory when closing and delete them.
>
> * lisp/emacs-lisp/comp.el (comp--replace-output-file): Function called=
> from C code to finish the compilation process. It performs renaming of=
> the old file if necessary.
> * lisp/emacs-lisp/package.el (package--delete-directory): Function to<= br> > delete a package directory. It moves native compilation units that it<= br> > can't delete to `package-user-dir'.
> * src/alloc.c (cleanup_vector): Call dispose_comp_unit().
>=C2=A0 =C2=A0(garbage_collect): Call finish_delayed_disposal_of_comp_un= its().
> * src/comp.c: Restore the signal mask using unwind-protect. Store
> loaded native compilation units in a hash table for disposal on
> close. Store filenames of native compilation units GC'd in a linke= d
> list to finish their disposal when the GC is over.

Please annotate in the changelog the new functions ex:
finish_delayed_disposal_of_comp_units, dispose_all_remaining_comp_units, register_native_comp_unit are missing.

> * src/comp.h: Introduce cfile member in Lisp_Native_Comp_Unit.
> Add declarations of functions that: clean directories of unused native=
> compilation units, handle disposal of native compilation units.
> * src/emacs.c (kill-emacs): Dispose all remaining compilation units > right right before calling exit().
> * src/eval.c (internal_condition_case_3, internal_condition_case_4): > Add functions.
> * src/lisp.h (internal_condition_case_3, internal_condition_case_4): > Add functions.
> * src/pdumper.c (dump_do_dump_relocation): Set cfile to a copy of the<= br> > Lisp string specifying the file path.

> diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> index 012baf2560..1fb4cd98c0 100644
> --- a/lisp/emacs-lisp/comp.el
> +++ b/lisp/emacs-lisp/comp.el
> @@ -2183,6 +2183,31 @@ comp-hint-cons
>=C2=A0
>=C2=A0 ;; Some entry point support code.
>
> +(defun comp--replace-output-file (outfile tmpfile)
> +=C2=A0 "Replace OUTFILE with TMPFILE taking the necessary steps = when
> +dealing with shared libraries that may be loaded into Emacs"
> +=C2=A0 (cond ((eq 'windows-nt system-type)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(ignore-errors (delete-file outfile= ))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((retry t))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(while retry
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setf retry nil)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(condition-case _
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(progn<= br> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ;; outfile maybe recreated by another Emacs in
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ;; between the following two rename-file calls
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (if (file-exists-p outfile)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0(rename-file outfile (make-temp-file-internal
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(file-name-sans-extension outfile)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0nil ".eln.old" nil)

Isn't better to just add .old? So we will have cases of foo.eln.old.old=
instead of foo.eln.old.eln.old ?

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (rename-file tmpfile outfile nil))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(file-already-= exists (setf retry t))))))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Remove the old eln instead of copying = the new one into it
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; to get a new inode and prevent crashes= in case the old one
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; is currently loaded.
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (t (delete-file outfile)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(rename-file tmpfile outfile= ))))
> +
>=C2=A0 (defvar comp-files-queue ()
>=C2=A0 =C2=A0 "List of Elisp files to be compiled.")



> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > index 95659840ad..c1c54b3c9a 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -2184,6 +2184,31 @@ If some packages are not installed propose to i= nstall them."
>=C2=A0 =C2=A0 (equal (cadr (assq (package-desc-name pkg) package-alist)= )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pkg))
>
> +(defun package--delete-directory (dir)
> +=C2=A0 "Delete DIR recursively.
> +In Windows move .eln and .eln.old files that can not be deleted to `p= ackage-user-dir'."

80 column lines limit.=C2=A0 I think also this should be transparent when native-comp-available-p say native comp is not available (for now
compiler and load machinery are bundled).

> +=C2=A0 (cond ((eq 'windows-nt system-type)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((retry t))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(while retry
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setf retry nil)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(condition-case err > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(delete= -directory dir t)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(file-error > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if (and (str= ing=3D "Removing old name" (cadr err))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(string=3D "Permission denied" (caddr err))<= br> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(or (string-suffix-p ".eln" (cadddr err)) > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(string-suffix-p ".eln.old" (c= adddr err))))

I think would be good to destructure err using something like
cl-destructuring-bind or pcase or even just using a let + some naming to make this more readable.

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (progn
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 (rename-file (cadddr err)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(make-temp-file-int= ernal
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (concat package-us= er-dir
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (file-name-base (cadddr err)))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nil ".eln.old= " nil)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 (setf retry t))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (signa= l (car err) (cdr err))))))))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 (t (delete-directory dir t))))
> +
>=C2=A0 (defun package-delete (pkg-desc &optional force nosave)
>=C2=A0 =C2=A0 "Delete package PKG-DESC.
>
> @@ -2236,7 +2261,7 @@ If NOSAVE is non-nil, the package is not removed= from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= package-desc-name pkg-used-elsewhere-by)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(add-hook 'post-com= mand-hook #'package-menu--post-refresh)
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(delete-directory dir t)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(package--delete-directory d= ir)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Remove NAME-VERSION.= signed and NAME-readme.txt files.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; NAME-readme.txt file= s are no longer created, but they
> diff --git a/src/alloc.c b/src/alloc.c
> index d6ba4d9790..420168ec4d 100644
> --- a/src/alloc.c
> +++ b/src/alloc.c
> @@ -3119,8 +3119,7 @@ cleanup_vector (struct Lisp_Vector *vector)
>=C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Lisp_Native_Comp_Unit *cu =3D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0PSEUDOVEC_STRUCT (vector, Lisp_Native_Comp_U= nit);
> -=C2=A0 =C2=A0 =C2=A0 eassert (cu->handle);
> -=C2=A0 =C2=A0 =C2=A0 dynlib_close (cu->handle);
> +=C2=A0 =C2=A0 =C2=A0 dispose_comp_unit (cu, true);
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 }
>
> @@ -6117,6 +6116,8 @@ garbage_collect (void)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (tot_after < tot_before)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0malloc_probe (min (tot_before - tot_after, S= IZE_MAX));
>=C2=A0 =C2=A0 =C2=A0 }
> +
> +=C2=A0 finish_delayed_disposal_of_comp_units ();

Could you describe why we need to call this each garbage collection?
Isn't sufficient to do it when emacs is exiting?

>=C2=A0 }
>
>=C2=A0 DEFUN ("garbage-collect", Fgarbage_collect, Sgarbage_c= ollect, 0, 0, "",
> diff --git a/src/comp.c b/src/comp.c
> index dd45599cc4..77c3006c56 100644
> --- a/src/comp.c
> +++ b/src/comp.c
> @@ -413,6 +413,10 @@ load_gccjit_if_necessary (bool mandatory)
>=C2=A0 #define CALL1I(fun, arg)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>=C2=A0 =C2=A0 CALLN (Ffuncall, intern_c_string (STR (fun)), arg)
>
> +/* Like call2 but stringify and intern.=C2=A0 */
> +#define CALL2I(fun, arg1, arg2)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
> +=C2=A0 CALLN (Ffuncall, intern_c_string (STR (fun)), arg1, arg2)
> +
>=C2=A0 #define DECL_BLOCK(name, func)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0\
>=C2=A0 =C2=A0 gcc_jit_block *(name) =3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
>=C2=A0 =C2=A0 =C2=A0 gcc_jit_function_new_block ((func), STR (name)) > @@ -3828,6 +3832,14 @@ DEFUN ("comp--release-ctxt", Fcomp__r= elease_ctxt, Scomp__release_ctxt,
>=C2=A0 =C2=A0 return Qt;
>=C2=A0 }
>
> +sigset_t oldset;

I think we have all static data at the top.

That said this is unclear to me because in comp--compile-ctxt-to-file
oldset is automatic and shadows this static, so I think we'll save in the the automatic and later we just restore the (always zeroed) static
one.

> +static void restore_sigmask(void)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space
> +{
> +=C2=A0 pthread_sigmask (SIG_SETMASK, &oldset, 0);
> +=C2=A0 unblock_input ();
> +}
> +
>=C2=A0 DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ct= xt_to_file,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Scomp__compile_ctxt_to_file,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01, 1, 0,
> @@ -3849,6 +3861,8 @@ DEFUN ("comp--compile-ctxt-to-file", F= comp__compile_ctxt_to_file,
>=C2=A0 =C2=A0 =C2=A0 CALL1I (comp-data-container-idx, CALL1I (comp-ctxt= -d-ephemeral, Vcomp_ctxt));
>
>=C2=A0 =C2=A0 sigset_t oldset;
> +=C2=A0 ptrdiff_t count;
> +
>=C2=A0 =C2=A0 if (!noninteractive)
>=C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sigset_t blocked;
> @@ -3861,6 +3875,8 @@ DEFUN ("comp--compile-ctxt-to-file", F= comp__compile_ctxt_to_file,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sigaddset (&blocked, SIGIO);
>=C2=A0 #endif
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pthread_sigmask (SIG_BLOCK, &blocked, &= amp;oldset);
> +=C2=A0 =C2=A0 =C2=A0 count =3D SPECPDL_INDEX ();
> +=C2=A0 =C2=A0 =C2=A0 record_unwind_protect_void(restore_sigmask);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 space

>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 emit_ctxt_code ();
>
> @@ -3899,18 +3915,10 @@ DEFUN ("comp--compile-ctxt-to-file",= Fcomp__compile_ctxt_to_file,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GCC_JIT_OUTPUT_KIND_DYNAMI= C_LIBRARY,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSDATA (tmp_file));
>
> -=C2=A0 /* Remove the old eln instead of copying the new one into it t= o get
> -=C2=A0 =C2=A0 =C2=A0a new inode and prevent crashes in case the old o= ne is currently
> -=C2=A0 =C2=A0 =C2=A0loaded.=C2=A0 */
> -=C2=A0 if (!NILP (Ffile_exists_p (out_file)))
> -=C2=A0 =C2=A0 Fdelete_file (out_file, Qnil);
> -=C2=A0 Frename_file (tmp_file, out_file, Qnil);
> +=C2=A0 CALL2I(comp--replace-output-file, out_file, tmp_file);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 space
>
>=C2=A0 =C2=A0 if (!noninteractive)
> -=C2=A0 =C2=A0 {
> -=C2=A0 =C2=A0 =C2=A0 pthread_sigmask (SIG_SETMASK, &oldset, 0); > -=C2=A0 =C2=A0 =C2=A0 unblock_input ();
> -=C2=A0 =C2=A0 }
> +=C2=A0 =C2=A0 unbind_to(count, Qnil);
>
>=C2=A0 =C2=A0 return out_file;
>=C2=A0 }
> @@ -3972,6 +3980,138 @@ helper_PSEUDOVECTOR_TYPEP_XUNTAG (Lisp_Object = a, enum pvec_type code)
>=C2=A0 }
>
>=C2=A0
> +/*********************************/
> +/* Disposal of compilation units */
> +/*********************************/
> +
> +#ifdef WINDOWSNT
> +#define OLD_ELN_SUFFIX_REGEXP build_string("\\.eln\\.old$")=

I think instead of $=C2=A0 \\' is more correct.

> +static Lisp_Object all_loaded_comp_units;

All hash table in this files are postfixed as _h

> +struct delayed_comp_unit_disposal
> +{
> +=C2=A0 struct delayed_comp_unit_disposal * next;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no space here > +=C2=A0 char * filename;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 likewise
> +};

Why an ad-hoc C structure and not a simple cons?=C2=A0 I think it would be<= br> simpler and safer to use just a lisp list here.=C2=A0 Is it because we need=
to add during GC?=C2=A0 If yes, comment :)

> +struct delayed_comp_unit_disposal * delayed_comp_unit_disposal_list;<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likewise and the= followings
> +
> +static Lisp_Object
> +returnQnil (Lisp_Object arg)

No camel case in function names.

> +{
> +=C2=A0 return Qnil;
> +}

I think each of the following functions really needs a comment line to
explain the scope of each of them + one preamble comment to explain all
the rename mechanism how is expected to work and the two datastructures
involved.

> +static void
> +clean_comp_unit_directory (Lisp_Object filepath)
> +{
> +=C2=A0 if (NILP (filepath))
> +=C2=A0 =C2=A0 return;
> +=C2=A0 Lisp_Object files_in_dir;
> +=C2=A0 files_in_dir =3D internal_condition_case_4(Fdirectory_files, f= ilepath, Qt,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0OLD_ELN_SUFFIX_REGEXP, Qnil, Qt, returnQnil);

80 columns

> +=C2=A0 FOR_EACH_TAIL(files_in_dir)
> +=C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 DeleteFile (SSDATA (XCAR (files_in_dir)));
> +=C2=A0 =C2=A0 }
> +}
> +
> +void clean_package_user_dir_of_old_comp_units (void)
=C2=A0 =C2=A0 =C2=A0 ^^^
=C2=A0 =C2=A0 =C2=A0 new lines
> +{
> +=C2=A0 Lisp_Object package_user_dir =3D find_symbol_value (intern (&q= uot;package-user-dir"));
> +=C2=A0 if (EQ(package_user_dir, Qunbound) || !STRINGP(package_user_di= r))
> +=C2=A0 =C2=A0 return;
> +
> +=C2=A0 clean_comp_unit_directory(package_user_dir);
> +}
> +
> +#endif
> +
> +void dispose_comp_unit (struct Lisp_Native_Comp_Unit * comp_handle, b= ool delay)
=C2=A0 =C2=A0 =C2=A0 ^^^
=C2=A0 =C2=A0 =C2=A0 likewise
> +{
> +=C2=A0 eassert (comp_handle->handle);
> +=C2=A0 dynlib_close (comp_handle->handle);
> +#ifdef WINDOWSNT
> +=C2=A0 if (!delay)
> +=C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 Lisp_Object dirname =3D internal_condition_case_= 1(Ffile_name_directory,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 build_string (comp_handle->= ;cfile),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Qt,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returnQnil);
> +=C2=A0 =C2=A0 =C2=A0 if (!NILP(dirname))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 clean_comp_unit_directory (dirname);

I think we need to comment here why when we dispose the compilation unit we try to clean the full directory.

> +=C2=A0 =C2=A0 =C2=A0 xfree (comp_handle->cfile);
> +=C2=A0 =C2=A0 =C2=A0 comp_handle->cfile =3D NULL;
> +=C2=A0 =C2=A0 }
> +=C2=A0 else
> +=C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 struct delayed_comp_unit_disposal * head;
> +=C2=A0 =C2=A0 =C2=A0 head =3D xmalloc (sizeof (struct delayed_comp_un= it_disposal));
> +=C2=A0 =C2=A0 =C2=A0 head->next =3D delayed_comp_unit_disposal_lis= t;
> +=C2=A0 =C2=A0 =C2=A0 head->filename =3D comp_handle->cfile;
> +=C2=A0 =C2=A0 =C2=A0 comp_handle->cfile =3D NULL;
> +=C2=A0 =C2=A0 =C2=A0 delayed_comp_unit_disposal_list =3D head;
> +=C2=A0 =C2=A0 }
> +#else
> +=C2=A0 xfree (comp_handle->file);
> +#endif
> +}

Also, wasn't the plan to try to delete the file and in case of failure<= br> to put it in a list?=C2=A0 Here when delay is true this goes directly in th= e
list.=C2=A0 Could you explain why and add comment?

> +static void
> +register_native_comp_unit (Lisp_Object comp_u)
> +{
> +#ifdef WINDOWSNT
> +=C2=A0 static EMACS_UINT count;
> +
> +=C2=A0 if (XFIXNUM(Fhash_table_count(all_loaded_comp_units)) >=3D = MOST_POSITIVE_FIXNUM)
> +=C2=A0 =C2=A0 return;
> +
> +=C2=A0 while (!NILP(Fgethash(make_fixnum(count), all_loaded_comp_unit= s, Qnil)))
> +=C2=A0 =C2=A0 count =3D (count + 1) % MOST_POSITIVE_FIXNUM;

Given you are doing all of this just to get a key (we'll not use) I
think would be wise to just create the key using gensym.

> +=C2=A0 Fputhash(make_fixnum(count), comp_u, all_loaded_comp_units); > +#endif
> +}
>
> +void dispose_all_remaining_comp_units (void)
> +{
> +#ifdef WINDOWSNT
> +=C2=A0 struct Lisp_Hash_Table *h =3D XHASH_TABLE (all_loaded_comp_uni= ts);
> +
> +=C2=A0 for (ptrdiff_t i =3D 0; i < HASH_TABLE_SIZE (h); ++i)
> +=C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 Lisp_Object k =3D HASH_KEY (h, i);
> +=C2=A0 =C2=A0 =C2=A0 if (!EQ (k, Qunbound))
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lisp_Object val =3D HASH_VALUE (h,= i);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Lisp_Native_Comp_Unit * cu = =3D XNATIVE_COMP_UNIT(val);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dispose_comp_unit(cu, false);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> +=C2=A0 =C2=A0 }
> +#endif
> +}
> +



> +void finish_delayed_disposal_of_comp_units (void)
> +{
> +#ifdef WINDOWSNT
> +=C2=A0 for (struct delayed_comp_unit_disposal * item =3D delayed_comp= _unit_disposal_list;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0delayed_comp_unit_disposal_list;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0item =3D delayed_comp_unit_disposal_list)<= br> > +=C2=A0 =C2=A0 {
> +=C2=A0 =C2=A0 =C2=A0 delayed_comp_unit_disposal_list =3D item->nex= t;
> +=C2=A0 =C2=A0 =C2=A0 Lisp_Object dirname
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D internal_condition_case_1 (Ffile_name= _directory,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build_string= (item->filename), Qt,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returnQnil);=
> +=C2=A0 =C2=A0 =C2=A0 clean_comp_unit_directory (dirname);
> +=C2=A0 =C2=A0 =C2=A0 xfree(item->filename);
> +=C2=A0 =C2=A0 =C2=A0 xfree(item);
> +=C2=A0 =C2=A0 }
> +#endif
> +}
> +
> +=0C
>=C2=A0 /***********************************/
>=C2=A0 /* Deferred compilation mechanism. */
>=C2=A0 /***********************************/
> @@ -4192,6 +4332,12 @@ load_comp_unit (struct Lisp_Native_Comp_Unit *c= omp_u, bool loading_dump,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 d_vec_len =3D XFIXNUM (Flength (comp_u->= data_impure_vec));
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (EMACS_INT i =3D 0; i < d_vec_len; i= ++)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data_imp_relocs[i] =3D AREF (comp_u->data= _impure_vec, i);
> +
> +=C2=A0 =C2=A0 =C2=A0 /* If we register them while dumping we will get= some entries in
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the hash table that will be duplica= ted when pdumper calls
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load_comp_unit. */
> +=C2=A0 =C2=A0 =C2=A0 if (!will_dump_p())
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 register_native_comp_unit (comp_u_lisp_ob= j);
>=C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 if (!loading_dump)
> @@ -4349,6 +4495,9 @@ DEFUN ("native-elisp-load", Fnative_el= isp_load, Snative_elisp_load, 1, 2, 0,
>=C2=A0 =C2=A0 if (!comp_u->handle)
>=C2=A0 =C2=A0 =C2=A0 xsignal2 (Qnative_lisp_load_failed, file, build_st= ring (dynlib_error ()));
>=C2=A0 =C2=A0 comp_u->file =3D file;
> +#ifdef WINDOWSNT
> +=C2=A0 comp_u->cfile =3D xlispstrdup(file);
> +#endif
>=C2=A0 =C2=A0 comp_u->data_vec =3D Qnil;
>=C2=A0 =C2=A0 comp_u->lambda_gc_guard =3D CALLN (Fmake_hash_table, Q= Ctest, Qeq);
>=C2=A0 =C2=A0 comp_u->lambda_c_name_idx_h =3D CALLN (Fmake_hash_tabl= e, QCtest, Qequal);
> @@ -4497,6 +4646,11 @@ syms_of_comp (void)
>=C2=A0 =C2=A0 staticpro (&delayed_sources);
>=C2=A0 =C2=A0 delayed_sources =3D Qnil;
>
> +#ifdef WINDOWSNT
> +=C2=A0 staticpro (&all_loaded_comp_units);
> +=C2=A0 all_loaded_comp_units =3D CALLN(Fmake_hash_table, QCweakness, = Qvalue);
> +#endif
> +
>=C2=A0 =C2=A0 DEFVAR_LISP ("comp-ctxt", Vcomp_ctxt,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 doc: /* The compiler c= ontext.=C2=A0 */);
>=C2=A0 =C2=A0 Vcomp_ctxt =3D Qnil;
> diff --git a/src/comp.h b/src/comp.h
> index 36e7cdf441..0b790fc7cb 100644
> --- a/src/comp.h
> +++ b/src/comp.h
> @@ -52,7 +52,15 @@ struct Lisp_Native_Comp_Unit
>=C2=A0 =C2=A0 /* STUFFS WE DO NOT DUMP!!=C2=A0 */
>=C2=A0 =C2=A0 Lisp_Object *data_imp_relocs;
>=C2=A0 =C2=A0 bool loaded_once;
> +
>=C2=A0 =C2=A0 dynlib_handle_ptr handle;
> +#ifdef WINDOWSNT
> +=C2=A0 /* We need to store a copy of the original file name in memory= that
> +=C2=A0 =C2=A0 =C2=A0is not subject to GC because the function to disp= ose native
> +=C2=A0 =C2=A0 =C2=A0compilation units is called by the GC. By that ti= me the `file'
> +=C2=A0 =C2=A0 =C2=A0string may have been sweeped. */
> +=C2=A0 char * cfile;
> +#endif
>=C2=A0 };
>
>=C2=A0 #ifdef HAVE_NATIVE_COMP
> @@ -83,6 +91,14 @@ extern void syms_of_comp (void);
>
>=C2=A0 extern void maybe_defer_native_compilation (Lisp_Object function= _name,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Lisp_Object definition);
> +
> +extern void dispose_comp_unit (struct Lisp_Native_Comp_Unit *
>=C2=A0 comp_unit, bool delay);
> +
> +extern void finish_delayed_disposal_of_comp_units (void);
> +
> +extern void dispose_all_remaining_comp_units (void);
> +
> +extern void clean_package_user_dir_of_old_comp_units (void);
>=C2=A0 #else
>
>=C2=A0 static inline void
> @@ -92,6 +108,17 @@ maybe_defer_native_compilation (Lisp_Object functi= on_name,
>
>=C2=A0 extern void syms_of_comp (void);
>
> +static inline void dispose_comp_unit (struct Lisp_Native_Comp_Unit * = comp_handle)

Newline after ret type for this and the following definitions.

> +{
> +=C2=A0 emacs_abort();
> +}

emacs_abort is still not declared here so it does not compile.=C2=A0 Maybe = we
can just put an eassert (false).

> +static inline void dispose_all_remaining_comp_units (void)
> +{}
> +
> +static inline void clean_package_user_dir_of_old_comp_units (void) > +{}
> +


Thanks

=C2=A0 Andrea

--
akrl@sdf.org
--00000000000066748305a6594ffb-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 23:53:11 2020 Received: (at 41242) by debbugs.gnu.org; 24 May 2020 03:53:11 +0000 Received: from localhost ([127.0.0.1]:36139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jchhH-0006b7-Di for submit@debbugs.gnu.org; Sat, 23 May 2020 23:53:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jchhF-0006av-RB for 41242@debbugs.gnu.org; Sat, 23 May 2020 23:53:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54525) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jchhA-0001Ot-Dk; Sat, 23 May 2020 23:53:04 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jchh9-0000M1-AR; Sat, 23 May 2020 23:53:03 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83sgfqxztr.fsf@gnu.org> (message from Eli Zaretskii on Sat, 23 May 2020 21:37:20 +0300) Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> <83sgfqxztr.fsf@gnu.org> Message-Id: Date: Sat, 23 May 2020 23:53:03 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org, akrl@sdf.org 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: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Maybe the developers of Spacemacs should help write code to speed up that case. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 04:19:11 2020 Received: (at 41242) by debbugs.gnu.org; 24 May 2020 08:19:11 +0000 Received: from localhost ([127.0.0.1]:36427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jclqg-0004n8-V7 for submit@debbugs.gnu.org; Sun, 24 May 2020 04:19:11 -0400 Received: from mx.sdf.org ([205.166.94.20]:58025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jclqe-0004mz-Oo for 41242@debbugs.gnu.org; Sun, 24 May 2020 04:19:09 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04O8J7cU021207 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 24 May 2020 08:19:07 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04O8J7kC006244; Sun, 24 May 2020 08:19:07 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Sun, 24 May 2020 08:19:07 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 23 May 2020 20:43:06 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi Andrea, > > Thanks for the feedback. > >> Please review all the GNU code-style of this diff.=C2=A0 I've annotated > some >> to be fixed but there are quite a number more of fixes of the same > kind >> to be done. > > This is such a pain, I sometimes forget to change Emacs to GNU style > and > sometimes I'll write GNU style at work. Isn't this good? ;) Joking aside, you can also set it on a directory base. Another trick if your are not mechanically used to C GNU style is to run check_GNU_style.sh on your patch (comes in the contrib folder of GCC). >> > +(defun comp--replace-output-file (outfile tmpfile) >> > + =C2=A0"Replace OUTFILE with TMPFILE taking the necessary steps when >> > +dealing with shared libraries that may be loaded into Emacs" >> > + =C2=A0(cond ((eq 'windows-nt system-type) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ignore-errors (delete-file outfile)) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((retry t)) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (while retry >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setf retry nil) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (condition-case _ >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; ou= tfile maybe recreated by another Emacs > in >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; be= tween the following two rename-file > calls >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if (= file-exists-p outfile) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (rename-file outfile > (make-temp-file-internal >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 > (file-name-sans-extension outfile) >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 nil ".eln.old" nil) > >> Isn't better to just add .old? So we will have cases of > foo.eln.old.old >> instead of foo.eln.old.eln.old ? > > We can't do that because foo.eln.old might exist already. This code > tries to > rename an existing foo.eln to fooXXXXXX.eln.old where XXXXXX are > random. We > should never try to rename fooXXXXXX.eln.old if it already exists. Understand, I had in my mind was cleaner to add .old till the first non used filename available was found but I guess is the same, probably even simpler. >> > +(defun package--delete-directory (dir) >> > + =C2=A0"Delete DIR recursively. >> > +In Windows move .eln and .eln.old files that can not be deleted > to `package-user-dir'." > >> 80 column lines limit.=C2=A0 I think also this should be transparent > when >> native-comp-available-p say native comp is not available (for now >> compiler and load machinery are bundled). > > We might be trying to delete an .eln file that another Emacs instance > has > loaded. I know it sounds kind of strange, but if that is not the case > then > `package--delete-directory` will just call `delete-directory`. It doesn't sound strange. I see probably is better like this for systems running Emacs native-comp and stock at the same time. >> I think would be good to destructure err using something like >> cl-destructuring-bind or pcase or even just using a let + some > naming to >> make this more readable. > > Good idea. > >> > @@ -6117,6 +6116,8 @@ garbage_collect (void) >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (tot_after < tot_before) >> > =C2=A0 =C2=A0 =C2=A0 malloc_probe (min (tot_before - tot_after, SIZE_M= AX)); >> > =C2=A0 =C2=A0 =C2=A0} >> > + >> > + =C2=A0finish_delayed_disposal_of_comp_units (); > >> Could you describe why we need to call this each garbage > collection? >> Isn't sufficient to do it when emacs is exiting? > > I thought it was cleaner to delete *.eln.old ASAP. It would make it > necessary to > store the original files in a list, anyway. The problem is that GC is called (especially by default) *very* frequently, bounding GC performance to filesystem accesses is really not a good idea IMO because we have no control over this last. You could not see a difference here because: - spaceemacs GC settings runs it way less often coming with a bigger gc-cons-threshold by default - GC euristincs being GC slow decides to give-up a little and accept running less often leading to more fragmentation - filesystem is blazingly fast - you haven't measured ;) >> That said this is unclear to me because in > comp--compile-ctxt-to-file >> oldset is automatic and shadows this static, so I think we'll save > in >> the the automatic and later we just restore the (always zeroed) > static >> one. > > You are right. I'll fix it. > >> +struct delayed_comp_unit_disposal >> +{ >> + =C2=A0struct delayed_comp_unit_disposal * next; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no space here >> + =C2=A0char * filename; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^ > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 likewise >> +}; > >> Why an ad-hoc C structure and not a simple cons?=C2=A0 I think it would > be >> simpler and safer to use just a lisp list here.=C2=A0 Is it because we > need >> to add during GC?=C2=A0 If yes, comment :) > > Exactly. Since filename needs to be a C string, I figured that using > a C struct > would be simpler that trying to wrap the C string in a Lisp object. So the reason is not to allocate lisp objs during GC correct? >> I think each of the following functions really needs a comment line > to >> explain the scope of each of them + one preamble comment to explain > all >> the rename mechanism how is expected to work and the two > datastructures >> involved. > > Sure. > >> +{ >> + =C2=A0eassert (comp_handle->handle); >> + =C2=A0dynlib_close (comp_handle->handle); >> +#ifdef WINDOWSNT >> + =C2=A0if (!delay) >> + =C2=A0 =C2=A0{ >> + =C2=A0 =C2=A0 =C2=A0Lisp_Object dirname =3D internal_condition_case_1 > (Ffile_name_directory, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0build_string > (comp_handle->cfile), >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Qt, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returnQnil); >> + =C2=A0 =C2=A0 =C2=A0if (!NILP(dirname)) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0clean_comp_unit_directory (dirname); > >> I think we need to comment here why when we dispose the compilation > unit >> we try to clean the full directory. > > This is because ideally we'd try to delete fooXXXXXX.eln.old if we > are disposing > the "foo" compilation unit and the file has been renamed. It turns > out that > there is no simple way to figure out the current name of a loaded > module in > Windows. GetModuleFileName returns the filename it had at the time we > loaded it. > Deleting all the *.eln.old in the directory is the (simple) > workaround. Uh I see. I think this is worth noting with a comment in the code too. >> + =C2=A0 =C2=A0 =C2=A0xfree (comp_handle->cfile); >> + =C2=A0 =C2=A0 =C2=A0comp_handle->cfile =3D NULL; >> + =C2=A0 =C2=A0} >> + =C2=A0else >> + =C2=A0 =C2=A0{ >> + =C2=A0 =C2=A0 =C2=A0struct delayed_comp_unit_disposal * head; >> + =C2=A0 =C2=A0 =C2=A0head =3D xmalloc (sizeof (struct delayed_comp_unit= _disposal)); >> + =C2=A0 =C2=A0 =C2=A0head->next =3D delayed_comp_unit_disposal_list; >> + =C2=A0 =C2=A0 =C2=A0head->filename =3D comp_handle->cfile; >> + =C2=A0 =C2=A0 =C2=A0comp_handle->cfile =3D NULL; >> + =C2=A0 =C2=A0 =C2=A0delayed_comp_unit_disposal_list =3D head; >> + =C2=A0 =C2=A0} >> +#else >> + =C2=A0xfree (comp_handle->file); >> +#endif >> +} > >> Also, wasn't the plan to try to delete the file and in case of > failure >> to put it in a list?=C2=A0 Here when delay is true this goes directly in > the >> list.=C2=A0 Could you explain why and add comment? > > There are two reasons: > > We don't have a simple way of getting the current name of the module > (see > above). > > Deleting all the files in the directory is implemented using > Fdirectory_files, > that allocates Lisp objects, and doing that in the middle of a GC > sweep is cause > of crashes (already tried). > >> Given you are doing all of this just to get a key (we'll not use) I >> think would be wise to just create the key using gensym. > As said please annotate the ratio of this decisions in form of comments in the code, otherwise will be trick to follow for somebody who has not followed this thread. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 13:58:36 2020 Received: (at 41242) by debbugs.gnu.org; 24 May 2020 17:58:36 +0000 Received: from localhost ([127.0.0.1]:38646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcutQ-0006VV-4I for submit@debbugs.gnu.org; Sun, 24 May 2020 13:58:36 -0400 Received: from mail-oo1-f47.google.com ([209.85.161.47]:46173) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcutO-0006VI-BG for 41242@debbugs.gnu.org; Sun, 24 May 2020 13:58:34 -0400 Received: by mail-oo1-f47.google.com with SMTP id g22so3195869oop.13 for <41242@debbugs.gnu.org>; Sun, 24 May 2020 10:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H7uiPUwJp50TOV3Qxma72aHv9w1GzVV4NsYHB92gG1E=; b=CqTdOKUolbGOC124g97Vdu0qWoiW5wzGbjqDcIhkgCXLIXdX5TWBw8f6l1cXo1qLl+ 5FZlhanaAzdDPTfGzuxSD98Bfq9i+drDw9Lry0fglkVzNPBn2UZROuZ3YT1A0JVr8QUW FP2bRY8KLABYFWKDyxsHS4wpcxXjPIRufd7Si6ZvxOl9lk+ih0dhP+B2OjkraxQLd24b iODKmFdOrMjDEpbfFsZg0QzVcueA9uRDmtqG/lZvCNrorF+XyhvOD5VVjaSwwWN41d5I zYRXDINk5YHXPt5hfDGjqSGNGc/FYDfUtMerZ3WtEQICIH0dyDaK097x28fcZjW+kF3g bbtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H7uiPUwJp50TOV3Qxma72aHv9w1GzVV4NsYHB92gG1E=; b=pQN/bezEoamKVkNSntl9d+QNPgBE/rlhVXE4ulvwXqORfrMDWgdIxLJuJPDOE4FKer WstVscTOwQv0/uvn+Mb6qMOH4tU1nzexD7l+uAwiOd7tJN+nNZ1Yz/zZTxmm4Go99qlr 5btSWwKSwytBOP7q3aefLWA6HjlIp2eGiYAZJhKU9tOq2t3ct6k4A8TXI3vBYokBs5ys IwsOEkhqHAwBRIgOjn6flQwhDcObnaryIOV+I2DG5LJGkOlbIMX+JpCjycvDZb45teZz zYWXO8BJTnniGMGdET9opGlYS719ck4rz0FKdVeoZQMX/VIXxSiNwWmGtS7nuoXUnI6P ySeg== X-Gm-Message-State: AOAM53355pdVe0hedp9P/bzbK5VHdymD2RUCahOgnO0RrnrbdG55dIx4 05rjDz3AByf18hx69f/6uodEZ7ehLSDxuiLIP0U= X-Google-Smtp-Source: ABdhPJydYVcYK8YBWBgQKKMRdxNxyFQjN7R05AmsCiKA02Kx8i9EUfNlreh/t1/ACgJgY/kXDq32OM74n9jhAb8agcQ= X-Received: by 2002:a4a:ad0d:: with SMTP id r13mr10693053oon.22.1590343108417; Sun, 24 May 2020 10:58:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sun, 24 May 2020 14:58:15 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... To: Andrea Corallo Content-Type: multipart/alternative; boundary="0000000000000c5cb305a6689c45" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --0000000000000c5cb305a6689c45 Content-Type: text/plain; charset="UTF-8" > The problem is that GC is called (especially by default) *very* > frequently, bounding GC performance to filesystem accesses is really not > a good idea IMO because we have no control over this last. > > You could not see a difference here because: > > - spaceemacs GC settings runs it way less often coming with a bigger > gc-cons-threshold by default > > - GC euristincs being GC slow decides to give-up a little and accept > running less often leading to more fragmentation > > - filesystem is blazingly fast > > - you haven't measured ;) Actually unloading a native compilation unit is such an unfrequent operation that all that finish_delayed_disposal_of_comp_units() does is compare a pointer to NULL. It will not slowdown the GC at all. Anyway, I could change this to run on an idle timer or just handle it when Emacs closes. Which do you prefer? > So the reason is not to allocate lisp objs during GC correct? Correct. Nicolas --0000000000000c5cb305a6689c45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The problem is that GC is called (es= pecially by default) *very*
> frequently, bounding GC performance to = filesystem accesses is really not
> a good idea IMO because we have n= o control over this last.
>
> You could not see a difference he= re because:
>
> - spaceemacs GC settings runs it way less often= coming with a bigger
> =C2=A0 gc-cons-threshold by default
>> - GC euristincs being GC slow decides to give-up a little and accept=
> =C2=A0 running less often leading to more fragmentation
>> - filesystem is blazingly fast
>
> - you haven't meas= ured ;)

Actually unloading a native compilation unit is such an unfr= equent operation
that all that finish_delayed_disposal_of_comp_units() d= oes is compare a pointer
to NULL. It will not slowdown the GC at all.
Anyway, I could change this to run on an idle timer or just handle it = when Emacs
closes. Which do you prefer?

> So the reason is not= to allocate lisp objs during GC correct?

Correct.

Nicolas
--0000000000000c5cb305a6689c45-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 15:14:03 2020 Received: (at 41242) by debbugs.gnu.org; 24 May 2020 19:14:03 +0000 Received: from localhost ([127.0.0.1]:38762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcw4Q-0008U5-Vz for submit@debbugs.gnu.org; Sun, 24 May 2020 15:14:03 -0400 Received: from mx.sdf.org ([205.166.94.20]:65476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcw4O-0008TX-Mm for 41242@debbugs.gnu.org; Sun, 24 May 2020 15:14:01 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04OJDxdO022681 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 24 May 2020 19:13:59 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04OJDxpP030955; Sun, 24 May 2020 19:13:59 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Sun, 24 May 2020 19:13:59 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sun, 24 May 2020 14:58:15 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> The problem is that GC is called (especially by default) *very* >> frequently, bounding GC performance to filesystem accesses is > really not >> a good idea IMO because we have no control over this last. >> >> You could not see a difference here because: >> >> - spaceemacs GC settings runs it way less often coming with a > bigger >> =C2=A0 gc-cons-threshold by default >> >> - GC euristincs being GC slow decides to give-up a little and > accept >> =C2=A0 running less often leading to more fragmentation >> >> - filesystem is blazingly fast >> >> - you haven't measured ;) > > Actually unloading a native compilation unit is such an unfrequent > operation > that all that finish_delayed_disposal_of_comp_units() does is compare > a pointer > to NULL. It will not slowdown the GC at all. > > Anyway, I could change this to run on an idle timer or just handle it > when Emacs > closes. Which do you prefer? What you say is correct, collecting a compilation unit is very infrequent now. But code could decide to native compile functions each time a performance critical operation has to be done, real world code does that already relying on the byte-compiler. I think to start with doing the clean-up when Emacs is closing is sufficient, we can always add the timer in case we feel the need. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 15:43:32 2020 Received: (at 41242) by debbugs.gnu.org; 24 May 2020 19:43:32 +0000 Received: from localhost ([127.0.0.1]:38841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcwWx-0000mb-RQ for submit@debbugs.gnu.org; Sun, 24 May 2020 15:43:32 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]:35416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcwWv-0000mN-2Q for 41242@debbugs.gnu.org; Sun, 24 May 2020 15:43:30 -0400 Received: by mail-ot1-f51.google.com with SMTP id 69so12415928otv.2 for <41242@debbugs.gnu.org>; Sun, 24 May 2020 12:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rDJQUuI/ik7QM7lEWhgIoKqRH3W4ypABV+hssGzXeac=; b=UtH3R0Xx0QHp35AKgzwgJ4NM+fLcAYdQYAQXSCqMcMLe9ZIkm2eEH7tl6BHzUCsYs9 DkLlBTaDvR3H3lgZtKP5h94oqWwzfbiGkjnW1ypljrNW7vyRss/Du7S84tNn1QFQ1kvx hq83KJn6FNNcBRe3DDBCKrXJ8wTIT5yDhIndqdnP7xZVzY4hPlzCfevV3r+gHtBYeSs9 nHicYdGSwc7s4JfKNmpVvi7tFj44/jPmzLnP6/bD+cPIaX7oIZvdAgbn2GzJrskAIOHf 6FULtu7WRISlHjNUhJFLNG+AjJqWnS0QL/+S2BXuAaWgJzJcRGwe6hS4/iP6lUm/5K8y FuoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rDJQUuI/ik7QM7lEWhgIoKqRH3W4ypABV+hssGzXeac=; b=bXsmL09EzRlH1nlQhmbOMpneYjWZf2+3wP6z74ml8b41wXbVmt5Va3lW0V9x1E6b8t QW2+I8ttyy8HoQtKPk+tulmx9eQw7PueWcrq2KUOMW7f9QWmhCrI9+YvzHmbWd0sk8t0 73UtSGIjJc2jZJC1be8ukkHC4uiiFSOt5ex1tX9tLbPlVUgQy+iWLzlfpg3AfnUcDBaF eN2LBHvZnUkF6hug1nYa4A7mrNPKQoj6n/AslVLkIqvC5/hWXSQY0fco9Gm3PTRF5P3a Ue9kTPIDvuE2jtQEjoU8EhbYjmvI6CPJfAaAy6c7xenrJ1VdLZgeO6hJpLi087ZpxPep z0IA== X-Gm-Message-State: AOAM531isbBFXc8bOzBIUkBTmMrr6I/zLmYlKSX/wMYZUP2q+781WeIc oKb9Dn/v65rQI3ZSV2rmXvOrqND8qIbEd+XDcuQ= X-Google-Smtp-Source: ABdhPJymJ8/4zb/hVannsWClT9H+I5ys+JtWwXaf5HVeNrgmBC00P/Rqc1XoY7KirEbvGPcS+9S4NXVE9daVbvLb1q4= X-Received: by 2002:a9d:191:: with SMTP id e17mr17843377ote.193.1590349403503; Sun, 24 May 2020 12:43:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sun, 24 May 2020 16:43:11 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... To: Andrea Corallo Content-Type: multipart/alternative; boundary="00000000000043c05e05a66a130d" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --00000000000043c05e05a66a130d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I pushed a new version of the patch to my git repo. Thanks, Nico El dom., 24 may. 2020 a las 16:14, Andrea Corallo () escribi= =C3=B3: > Nicolas B=C3=A9rtolo writes: > > >> The problem is that GC is called (especially by default) *very* > >> frequently, bounding GC performance to filesystem accesses is > > really not > >> a good idea IMO because we have no control over this last. > >> > >> You could not see a difference here because: > >> > >> - spaceemacs GC settings runs it way less often coming with a > > bigger > >> gc-cons-threshold by default > >> > >> - GC euristincs being GC slow decides to give-up a little and > > accept > >> running less often leading to more fragmentation > >> > >> - filesystem is blazingly fast > >> > >> - you haven't measured ;) > > > > Actually unloading a native compilation unit is such an unfrequent > > operation > > that all that finish_delayed_disposal_of_comp_units() does is compare > > a pointer > > to NULL. It will not slowdown the GC at all. > > > > Anyway, I could change this to run on an idle timer or just handle it > > when Emacs > > closes. Which do you prefer? > > What you say is correct, collecting a compilation unit is very > infrequent now. But code could decide to native compile functions each > time a performance critical operation has to be done, real world code > does that already relying on the byte-compiler. > > I think to start with doing the clean-up when Emacs is closing is > sufficient, we can always add the timer in case we feel the need. > > Thanks > > Andrea > > -- > akrl@sdf.org > --00000000000043c05e05a66a130d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I pushed a new version of the patch to my git repo.

Thanks, Nico

El dom., 24 may. 2020 a las 1= 6:14, Andrea Corallo (<akrl@sdf.org&= gt;) escribi=C3=B3:
Nicolas B=C3=A9rtolo <nicolasbertolo@gmail.com> writes:

>> The problem is that GC is called (especially by default) *very* >> frequently, bounding GC performance to filesystem accesses is
> really not
>> a good idea IMO because we have no control over this last.
>>
>> You could not see a difference here because:
>>
>> - spaceemacs GC settings runs it way less often coming with a
> bigger
>> =C2=A0 gc-cons-threshold by default
>>
>> - GC euristincs being GC slow decides to give-up a little and
> accept
>> =C2=A0 running less often leading to more fragmentation
>>
>> - filesystem is blazingly fast
>>
>> - you haven't measured ;)
>
> Actually unloading a native compilation unit is such an unfrequent
> operation
> that all that finish_delayed_disposal_of_comp_units() does is compare<= br> > a pointer
> to NULL. It will not slowdown the GC at all.
>
> Anyway, I could change this to run on an idle timer or just handle it<= br> > when Emacs
> closes. Which do you prefer?

What you say is correct, collecting a compilation unit is very
infrequent now.=C2=A0 But code could decide to native compile functions eac= h
time a performance critical operation has to be done, real world code
does that already relying on the byte-compiler.

I think to start with doing the clean-up when Emacs is closing is
sufficient, we can always add the timer in case we feel the need.

Thanks

=C2=A0 Andrea

--
akrl@sdf.org
--00000000000043c05e05a66a130d-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 08:21:10 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 12:21:10 +0000 Received: from localhost ([127.0.0.1]:40117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdC6O-0006bX-Hr for submit@debbugs.gnu.org; Mon, 25 May 2020 08:21:10 -0400 Received: from mx.sdf.org ([205.166.94.20]:54736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdC6J-0006bM-SV for 41242@debbugs.gnu.org; Mon, 25 May 2020 08:21:07 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04PCL2tc021474 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 25 May 2020 12:21:03 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04PCL2d7012638; Mon, 25 May 2020 12:21:02 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows References: <83a7227hkb.fsf@gnu.org> <83blmf13d1.fsf@gnu.org> <83367r0zvb.fsf@gnu.org> <83eerazlgw.fsf@gnu.org> <83367qzio7.fsf@gnu.org> <83zh9yy2of.fsf@gnu.org> <83y2piy0jt.fsf@gnu.org> <83sgfqxztr.fsf@gnu.org> Date: Mon, 25 May 2020 12:21:02 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 23 May 2020 19:52:14 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > I have come up with this patch to reduce the number of files > probed when `load' is called.. Yes, also if you are working in the area feel free to remove the effective_load_path approach because it breaks `load-prefer-newer'. If you are working on this I won't touch it not to conflict. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 10:05:01 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 14:05:01 +0000 Received: from localhost ([127.0.0.1]:42005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdDiv-00011y-3I for submit@debbugs.gnu.org; Mon, 25 May 2020 10:05:01 -0400 Received: from mx.sdf.org ([205.166.94.20]:58569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdDit-00011m-7m for 41242@debbugs.gnu.org; Mon, 25 May 2020 10:04:59 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04PE4ujI020921 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 25 May 2020 14:04:57 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04PE4u89007702; Mon, 25 May 2020 14:04:56 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Mon, 25 May 2020 14:04:56 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sun, 24 May 2020 16:43:11 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > I pushed a new version of the patch to my git repo. > > Thanks, Nico Hi Nico, I see the patch is adding internal_condition_case_3 and internal_condition_case_4 but I don't see them used. Is this a refuse of some previous version? Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 10:28:02 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 14:28:03 +0000 Received: from localhost ([127.0.0.1]:42058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdE5C-0001Zy-IO for submit@debbugs.gnu.org; Mon, 25 May 2020 10:28:02 -0400 Received: from mail-oi1-f174.google.com ([209.85.167.174]:35032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdE58-0001ZS-N1 for 41242@debbugs.gnu.org; Mon, 25 May 2020 10:28:01 -0400 Received: by mail-oi1-f174.google.com with SMTP id z9so11293076oid.2 for <41242@debbugs.gnu.org>; Mon, 25 May 2020 07:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xo+AvNxSx5AGf7V1cFn5NAobe8lDqX3ZVDM+dcOHxKk=; b=FlL6Mf1fY1UlMEvWCnbYvrR2TM9ziAexML8Zrk1giPlFQEtEz4ikvDawvHn/1SVKf/ ZTvFerdXHGBo9Fp+wGuf1GxnvvYsZF3RNaWPr8oS8XSvuwkpZHJFTJk1WLwlVRRAPp2q Av2Si5BOQuDNG6JNG9DZv41OQlhmAgSMGQyJkQXFS2FaaWiZJspqx5qjchJBswXiObqW DdRdzufDdGJJ9Eu520sMQ/nIhXyVWpIBZ3igfS5PeI8kMaC/zCKzu29p9+ZmFrWB3GI7 VIll+u2SRNjSLEVjJPoL6dQKMvV1GOIBTe9APaEyfRiYbqmjmQeV93wQXDrNe6BQb7iw OMSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xo+AvNxSx5AGf7V1cFn5NAobe8lDqX3ZVDM+dcOHxKk=; b=J7lOISp4jhmZ1W/wYOxXZojc+YnFOGLiUYpDJSqJjj9y2dGbceOVEe2jVAwNWogLD5 ZVrCy+CuloY/mR7HtA+YmMVdFdwaxSXI4OlTCt1ArinlSFEPTfzVZpqX7J04rwC7GQrQ UcE20LPp3wS4coM3POTv9Zw6lEaBRh4uFQhDr4WphzO7k2Un6Ia8tSOrXKDTR4Xr4Ofj fUsfideqF8lUOhX6DN44KxdBQj6wO/Fh4KYVkF7fSgBATv9hAtMMVb++tNTHLoGdU0o7 ijL+gnp38jYyTIe0S+HnHw2ErF2LklT+Bo/GCmUnhMlyHN+MCrW5Pjq5p3gPXHandJIF NUCw== X-Gm-Message-State: AOAM5311ehEwD3j8To9xgQ8N0AOJRojjeNDxAvJjWAZA83LKnIbIhrbo H0z7JuUsZ4BtBQiHwE1MFRZuYEPmWTn7U7Shtuw= X-Google-Smtp-Source: ABdhPJyhVIiDXZDgy0RLWgRyddsMEJd7SnRcotACzw/jSH2K/w2efeZxVbrfidZSjlZvkIEEh06prg5cXpKypGya0nQ= X-Received: by 2002:a54:4701:: with SMTP id k1mr11524100oik.175.1590416873093; Mon, 25 May 2020 07:27:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Mon, 25 May 2020 11:27:39 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... To: Andrea Corallo Content-Type: multipart/alternative; boundary="000000000000c4005305a679c883" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000c4005305a679c883 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrea, > I see the patch is adding internal_condition_case_3 and > internal_condition_case_4 but I don't see them used. Is this a refuse > of some previous version? internal_condition_case_4 is used in clean_comp_unit_directory(). internal_condition_case_3 is not used, but I added it for completeness. I have pushed a new patch that reduces the number of files probed when loading. It should work for Posix too. Nico El lun., 25 may. 2020 a las 11:05, Andrea Corallo () escribi= =C3=B3: > Nicolas B=C3=A9rtolo writes: > > > I pushed a new version of the patch to my git repo. > > > > Thanks, Nico > > Hi Nico, > > I see the patch is adding internal_condition_case_3 and > internal_condition_case_4 but I don't see them used. Is this a refuse > of some previous version? > > Thanks > > Andrea > > -- > akrl@sdf.org > --000000000000c4005305a679c883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrea,

> I see the patch is adding internal_condition_case_3 and
> internal_condition_case_4 but I don't see them used.=C2=A0 Is this= a refuse
> of some previous version?=C2=A0

internal_cond= ition_case_4 is used in clean_comp_unit_directory().
internal_con= dition_case_3 is not used, but I added it for completeness.

<= /div>
I have pushed a new patch that reduces the number of files probed= when loading.
It should work for Posix too.

=
Nico


El lun., 25 may. 2020 a las 11:05, Andrea= Corallo (<akrl@sdf.org>) escribi= =C3=B3:
Nicolas = B=C3=A9rtolo <nicolasbertolo@gmail.com> writes:

> I pushed a new version of the patch to my git repo.
>
> Thanks, Nico

Hi Nico,

I see the patch is adding internal_condition_case_3 and
internal_condition_case_4 but I don't see them used.=C2=A0 Is this a re= fuse
of some previous version?

Thanks

=C2=A0 Andrea

--
akrl@sdf.org
--000000000000c4005305a679c883-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 11:06:30 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 15:06:30 +0000 Received: from localhost ([127.0.0.1]:42135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdEgP-0006oJ-PS for submit@debbugs.gnu.org; Mon, 25 May 2020 11:06:29 -0400 Received: from mx.sdf.org ([205.166.94.20]:49603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdEgN-0006oB-L6 for 41242@debbugs.gnu.org; Mon, 25 May 2020 11:06:28 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04PF6QDP001939 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 25 May 2020 15:06:26 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04PF6Qt9009535; Mon, 25 May 2020 15:06:26 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Mon, 25 May 2020 15:06:26 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Mon, 25 May 2020 11:27:39 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi Andrea, > >> I see the patch is adding internal_condition_case_3 and >> internal_condition_case_4 but I don't see them used.=C2=A0 Is this a > refuse >> of some previous version?=C2=A0 > > internal_condition_case_4 is used in clean_comp_unit_directory(). > internal_condition_case_3 is not used, but I added it for > completeness. Ops sorry, doing last checks in parallel to other stuffs I failed to search correctly :/ Okay, have a look just pushed. > I have pushed a new patch that reduces the number of files probed > when loading. > It should work for Posix too. Super, I'll have a look this evening. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 16:27:49 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 20:27:49 +0000 Received: from localhost ([127.0.0.1]:42624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdJhA-0004Gd-J8 for submit@debbugs.gnu.org; Mon, 25 May 2020 16:27:49 -0400 Received: from mx.sdf.org ([205.166.94.20]:64755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdJh6-0004GO-Ey for 41242@debbugs.gnu.org; Mon, 25 May 2020 16:27:35 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04PKRVgc023623 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 25 May 2020 20:27:31 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04PKRVqI001645; Mon, 25 May 2020 20:27:31 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... References: Date: Mon, 25 May 2020 20:27:31 +0000 In-Reply-To: (Andrea Corallo's message of "Mon, 25 May 2020 15:06:26 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Andrea Corallo writes: > Nicolas B=C3=A9rtolo writes: > >> Hi Andrea, >> >>> I see the patch is adding internal_condition_case_3 and >>> internal_condition_case_4 but I don't see them used.=C2=A0 Is this a >> refuse >>> of some previous version?=C2=A0 >> >> internal_condition_case_4 is used in clean_comp_unit_directory(). >> internal_condition_case_3 is not used, but I added it for >> completeness. > > Ops sorry, doing last checks in parallel to other stuffs I failed to > search correctly :/ > > Okay, have a look just pushed. > >> I have pushed a new patch that reduces the number of files probed >> when loading. >> It should work for Posix too. > > Super, I'll have a look this evening. > > Thanks > > Andrea Hi Nico, please put the two patches in GNU code style, as mentioned you can run check_GNU_style.sh and check against the output. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 17:49:46 2020 Received: (at 41242) by debbugs.gnu.org; 25 May 2020 21:49:46 +0000 Received: from localhost ([127.0.0.1]:42653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdKyg-0008Ll-Jr for submit@debbugs.gnu.org; Mon, 25 May 2020 17:49:46 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:35112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdKyf-0008La-OD for 41242@debbugs.gnu.org; Mon, 25 May 2020 17:49:46 -0400 Received: by mail-ot1-f47.google.com with SMTP id 69so14769058otv.2 for <41242@debbugs.gnu.org>; Mon, 25 May 2020 14:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TNMLQKfxlzIucYRZrzatYokftdc9prHYWzJpg2XIdvE=; b=T3ymxgrvg5dpB5zZv/qvu9AVUE9Wmw3MJC277M9/DQQ5ZJkjtl1C82h5Wly6Dm5h2Z 9ZVVzFf0kv9eZ9o7Vw2S6wv/BYd1ASftJtmGm3dybw6M6QIo358vgXJVsXCfwgaQJKj/ rKzNZUFsMsfPNqv7YPvZqoC0RL6+y9BVJV9ciC7rz8j/Qfveefx5EditbQJDRZp6SyJ2 BHzgEDzVbK1tskeRZvrMHGWR0JKOvDKU19oOlJc5HBaSQJY+9tyYZzTCfjIp/DwULZf0 Jcm0E6dFWqjyc4JEWH4nEztrPg4Fa0F8qyP6B8Jg0kyRcbZxU1N6wSFQofcNeVBXiCLo e5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TNMLQKfxlzIucYRZrzatYokftdc9prHYWzJpg2XIdvE=; b=iS/BJJETkYeKNO3VRnxKVuLvX3aFUu6fvEIfRsQAw23qf0ceCxclzAJ1FUx++EkEfa ILDK7/S3fm8T//y9+A1q8JbEIsyNHh2u0IdTOPR+mkct2YuRk8k9BDO/lgFfesfQYQUU LG/ZHbSLDvHh1NXx/ZaH47wGg4/oLUHLsvvN3BNSz4QG3YoF7OavcXATAIOnxm48qWkl CRUVRnaajjhacYdXcH/oCegh6QnSPdjqAIqmWAvGyyb5tWZkkyoz7ZN/jDRDC/RQNFwh WUd/mrHKBrjfQn8G4W66U9Dk7fQR+7e1DtuCZsvOCGnRewKGep+1Q7YkPfRDAZlEUhFO Zrtw== X-Gm-Message-State: AOAM530TNhizvVP9p3hmnBWQN5tYNC3hJn4YKPYdSf0YVKhRpYDonjbR Hg7xXCwdF/fWgjESsoApxd5xLPfn/e0BXuMkkKA= X-Google-Smtp-Source: ABdhPJy/ixYSvewWzlkdC2qxNo4tbvvce27p/NGjPvJ/DfSs64km9QZL1sB0RNJ0O8eU8pkV9MLne29ESEy6dpVg+ik= X-Received: by 2002:a9d:191:: with SMTP id e17mr21341189ote.193.1590443380129; Mon, 25 May 2020 14:49:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Mon, 25 May 2020 18:49:27 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation... To: Andrea Corallo Content-Type: multipart/alternative; boundary="000000000000b542de05a67ff4a5" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000b542de05a67ff4a5 Content-Type: text/plain; charset="UTF-8" > please put the two patches in GNU code style, as mentioned you can run > check_GNU_style.sh and check against the output. It should be correct now. Nico --000000000000b542de05a67ff4a5 Content-Type: text/html; charset="UTF-8"
> please put the two patches in GNU code style, as mentioned you can run
> check_GNU_style.sh and check against the output.
It should be correct now.

Nico
--000000000000b542de05a67ff4a5-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 27 17:02:52 2020 Received: (at 41242) by debbugs.gnu.org; 27 May 2020 21:02:52 +0000 Received: from localhost ([127.0.0.1]:50110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je3CN-0005IE-KN for submit@debbugs.gnu.org; Wed, 27 May 2020 17:02:52 -0400 Received: from mx.sdf.org ([205.166.94.20]:63215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je3CM-0005I2-67 for 41242@debbugs.gnu.org; Wed, 27 May 2020 17:02:51 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04RL2kKa006746 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 27 May 2020 21:02:46 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04RL2k5K031715; Wed, 27 May 2020 21:02:46 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: Date: Wed, 27 May 2020 21:02:45 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 16:26:57 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain Hi all, I've attached the current Nico's patch in case someone wants to engage, here some comments from me. > * src/fileio.c: Introduce function emacs_root_dir(). Refactor > `expand-file-name` to use it. > * src/lisp.h: Separate emacs_root_dir() into dos_emacs_root_dir() and > w32_emacs_root_dir(). > * src/msdos.c: Rename emacs_root_dir() to dos_emacs_root_dir(). > * src/w32.c: Rename emacs_root_dir() to w32_emacs_root_dir(). I think would be good to mention in the commit message/changelog the reason of this change, why it wasn't working and why it is now. > diff --git a/src/fileio.c b/src/fileio.c > index 2f1d2f8243..e9be811841 100644 > --- a/src/fileio.c > +++ b/src/fileio.c > @@ -781,6 +781,18 @@ user_homedir (char const *name) > return pw->pw_dir; > } > > +static Lisp_Object > +emacs_root_dir (void) > +{ > +#ifdef DOS > + return build_string (dos_emacs_root_dir ()); > +#elif defined (WINDOWSNT) > + return build_string (w32_emacs_root_dir ()); > +#else > + return build_string ("/"); > +#endif > +} I believe the indentation of these returns should be two regular spaces. > DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, > doc: /* Convert filename NAME to absolute, and canonicalize it. > Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative > @@ -851,21 +863,16 @@ the root directory. */) > } > > /* As a last resort, we may have to use the root as > - default_directory below. */ > - Lisp_Object root; > -#ifdef DOS_NT > - /* "/" is not considered a root directory on DOS_NT, so using it > - as default_directory causes an infinite recursion in, e.g., > - the following: > + default_directory below. > > - (let (default-directory) > - (expand-file-name "a")) > + "/" is not considered a root directory on DOS_NT, so using it > + as default_directory causes an infinite recursion in, e.g., > + the following: > > - To avoid this, we use the root of the current drive. */ > - root = build_string (emacs_root_dir ()); > -#else > - root = build_string ("/"); > -#endif > + (let (default-directory) > + (expand-file-name "a")) > + > + To avoid this, we use the root of the current drive. */ I suspect this commentary is not very ideal here given now the code has been moved into emacs_root_dir, maybe the commentary should go there. > /* Use the buffer's default-directory if DEFAULT_DIRECTORY is omitted. */ > if (NILP (default_directory)) > @@ -891,13 +898,13 @@ the root directory. */) > Lisp_Object absdir > = STRINGP (Vinvocation_directory) > && file_name_absolute_no_tilde_p (Vinvocation_directory) > - ? Vinvocation_directory : root; > + ? Vinvocation_directory : emacs_root_dir (); > default_directory = Fexpand_file_name (dir, absdir); > } > } > } Thanks Andrea -- akrl@sdf.org --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Determine-the-emacs-root-dir-only-when-necessary.patch >From 1ead6bad59d0c2739dce13d3720c0264f2c5c531 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicol=C3=A1s=20B=C3=A9rtolo?= Date: Mon, 25 May 2020 17:55:23 -0300 Subject: [PATCH] Determine the emacs root dir only when necessary. * src/fileio.c: Introduce function emacs_root_dir(). Refactor `expand-file-name` to use it. * src/lisp.h: Separate emacs_root_dir() into dos_emacs_root_dir() and w32_emacs_root_dir(). * src/msdos.c: Rename emacs_root_dir() to dos_emacs_root_dir(). * src/w32.c: Rename emacs_root_dir() to w32_emacs_root_dir(). --- src/fileio.c | 37 ++++++++++++++++++++++--------------- src/lisp.h | 11 +++++++---- src/msdos.c | 2 +- src/w32.c | 2 +- 4 files changed, 31 insertions(+), 21 deletions(-) diff --git a/src/fileio.c b/src/fileio.c index 2f1d2f8243..e9be811841 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -781,6 +781,18 @@ user_homedir (char const *name) return pw->pw_dir; } +static Lisp_Object +emacs_root_dir (void) +{ +#ifdef DOS + return build_string (dos_emacs_root_dir ()); +#elif defined (WINDOWSNT) + return build_string (w32_emacs_root_dir ()); +#else + return build_string ("/"); +#endif +} + DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, doc: /* Convert filename NAME to absolute, and canonicalize it. Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative @@ -851,21 +863,16 @@ the root directory. */) } /* As a last resort, we may have to use the root as - default_directory below. */ - Lisp_Object root; -#ifdef DOS_NT - /* "/" is not considered a root directory on DOS_NT, so using it - as default_directory causes an infinite recursion in, e.g., - the following: + default_directory below. - (let (default-directory) - (expand-file-name "a")) + "/" is not considered a root directory on DOS_NT, so using it + as default_directory causes an infinite recursion in, e.g., + the following: - To avoid this, we use the root of the current drive. */ - root = build_string (emacs_root_dir ()); -#else - root = build_string ("/"); -#endif + (let (default-directory) + (expand-file-name "a")) + + To avoid this, we use the root of the current drive. */ /* Use the buffer's default-directory if DEFAULT_DIRECTORY is omitted. */ if (NILP (default_directory)) @@ -891,13 +898,13 @@ the root directory. */) Lisp_Object absdir = STRINGP (Vinvocation_directory) && file_name_absolute_no_tilde_p (Vinvocation_directory) - ? Vinvocation_directory : root; + ? Vinvocation_directory : emacs_root_dir (); default_directory = Fexpand_file_name (dir, absdir); } } } if (! STRINGP (default_directory)) - default_directory = root; + default_directory = emacs_root_dir (); handler = Ffind_file_name_handler (default_directory, Qexpand_file_name); if (!NILP (handler)) diff --git a/src/lisp.h b/src/lisp.h index 52242791aa..3dd8b9ad14 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4749,10 +4749,13 @@ extern bool profiler_memory_running; extern void malloc_probe (size_t); extern void syms_of_profiler (void); -#ifdef DOS_NT -/* Defined in msdos.c, w32.c. */ -extern char *emacs_root_dir (void); -#endif /* DOS_NT */ +#ifdef MSDOS +/* Defined in msdos.c. */ +extern char *dos_emacs_root_dir (void); +#elif defined (WINDOWSNT) +/* Defined in w32.c. */ +extern char *w32_emacs_root_dir (void); +#endif /* MSDOS */ #ifdef HAVE_NATIVE_COMP INLINE bool diff --git a/src/msdos.c b/src/msdos.c index b5f06c99c3..0827cc96cd 100644 --- a/src/msdos.c +++ b/src/msdos.c @@ -3350,7 +3350,7 @@ getdefdir (int drive, char *dst) } char * -emacs_root_dir (void) +dos_emacs_root_dir (void) { static char root_dir[4]; diff --git a/src/w32.c b/src/w32.c index 38bbc49656..a3f5844574 100644 --- a/src/w32.c +++ b/src/w32.c @@ -3147,7 +3147,7 @@ init_environment (char ** argv) /* Called from expand-file-name when default-directory is not a string. */ char * -emacs_root_dir (void) +w32_emacs_root_dir (void) { static char root_dir[MAX_UTF8_PATH]; const char *p; -- 2.20.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 02:17:54 2020 Received: (at 41242) by debbugs.gnu.org; 28 May 2020 06:17:55 +0000 Received: from localhost ([127.0.0.1]:50756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeBrW-0002G6-Nu for submit@debbugs.gnu.org; Thu, 28 May 2020 02:17:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeBrV-0002Ft-80 for 41242@debbugs.gnu.org; Thu, 28 May 2020 02:17:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55678) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeBrP-0000LA-TU; Thu, 28 May 2020 02:17:47 -0400 Received: from [176.228.60.248] (port=2274 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jeBrP-0006pG-A4; Thu, 28 May 2020 02:17:47 -0400 Date: Thu, 28 May 2020 09:17:39 +0300 Message-Id: <83k10wshvg.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 27 May 2020 21:02:45 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Date: Wed, 27 May 2020 21:02:45 +0000 > Cc: 41242@debbugs.gnu.org > > I've attached the current Nico's patch in case someone wants to engage, > here some comments from me. I agree with all your comments. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 20:40:15 2020 Received: (at 41242) by debbugs.gnu.org; 29 May 2020 00:40:16 +0000 Received: from localhost ([127.0.0.1]:53369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeT4J-0000RV-P1 for submit@debbugs.gnu.org; Thu, 28 May 2020 20:40:15 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:36725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeT4I-0000RG-4z for 41242@debbugs.gnu.org; Thu, 28 May 2020 20:40:14 -0400 Received: by mail-ot1-f47.google.com with SMTP id h7so700027otr.3 for <41242@debbugs.gnu.org>; Thu, 28 May 2020 17:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UtgWlBcYSWhojxZZZ+oWocDHPMw9O3jpZ8qzNf7csHQ=; b=uSLTtjA4j7FEQjMYo0tf8C7hGU8/aTiSxAli9hBOhiB5xChvcLkXkkc46ZJuFGsePe Vl/xl4DSgfXAPkBZvx4pKjGqFPRYUHU3976TD5OZ9mB9WEAQhNiLC8XJ+kJjTfemY5RG fZwFxOCE86Ggfn0lrl5YaVTc7wySq7hZXgYTzc6f26tAxafCdIQ1BOs6mctgC/w6QEsP qCrSrzWKrzHhXVTvwIH/GbDWUeWBPiTWcazrLIBzmwCzSVpDUAShyD6zu5gmUAZKjQPV EH6d/tcfJKas0cMaosUTYejVCainWZNFCW96vN3phY96JSV9knh2UAZ78nBka82ED+cU 3A+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UtgWlBcYSWhojxZZZ+oWocDHPMw9O3jpZ8qzNf7csHQ=; b=EsUwYy7EFeUaPbQ+l9kBEktE83QnN0181Ik+NOaI3iom84S+63V0RUWHLTPTySl1AF ET3hXqfE1RQBQo5sioDib28Mv5W7rA2iwFq3daTtcPhGib/oDJpFdaRpwrkSJ/6MXDQe 3m6xyxDBDs9N0/9beITQ6Pp+/wT0dwjUSosGtl3clIdw5oNWk0ya08MMK3U+bxyTtOpy y92fCz3AYe7g2MkGd9eWYxEp+bV8gfMZl1arH7kl38ZXKJ1l4ZevO+6hf9N1oNlhfjHh /XVVK4s+oKh0BAiQh11lhG1dF6yEiLKwTlYwD95suxOUFPCkYMD8XWSmSczxp033OfOF GpCw== X-Gm-Message-State: AOAM531csqDwy3TjJKq6rlYPIhvbcUlFoS6xFheQui2dzn3+fMsZlTdk nBrARKNsCTA21zc50pElB9SGJlAN/OoQxoQiMno= X-Google-Smtp-Source: ABdhPJxaszsI12kQnRIvG/SYGF6VyQ/CHrU2UyNKX6uV+1jak6lAzSALMY6DmfJLzHR/2PmbKUH6cBADWHLnGaB+ioU= X-Received: by 2002:a05:6830:2439:: with SMTP id k25mr4050392ots.352.1590712808132; Thu, 28 May 2020 17:40:08 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: <83k10wshvg.fsf@gnu.org> From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Thu, 28 May 2020 21:39:55 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000df104505a6beaf18" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) --000000000000df104505a6beaf18 Content-Type: multipart/alternative; boundary="000000000000df104205a6beaf16" --000000000000df104205a6beaf16 Content-Type: text/plain; charset="UTF-8" Hi, I have taken your comments into consideration and updated the patch. Nicolas --000000000000df104205a6beaf16 Content-Type: text/html; charset="UTF-8"
Hi,

I have taken your comments into consideration and updated the patch.

Nicolas
--000000000000df104205a6beaf16-- --000000000000df104505a6beaf18 Content-Type: application/octet-stream; name="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Disposition: attachment; filename="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_karhaw9r0 RnJvbSA2MjgzNzM4NzI5Yjg5ODZhZmU2ZjZkN2UwMTE3YjBhMDRkM2ZmZWI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAyNSBNYXkgMjAyMCAxNzo1 NToyMyAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIERldGVybWluZSB0aGUgZW1hY3Mgcm9vdCBkaXIg b25seSB3aGVuIG5lY2Vzc2FyeS4KCldoZW4gbG9hZGluZyBhIGR1bXAgZmlsZSB0aGF0IGNvbnRh aW5zIG5hdGl2ZSBjb21waWxlZCBlbGlzcCB3ZSB0cnkgdG8KZmluZCB0aGUgLmVsbiBmaWxlLiBU aGlzIHVzZXMgRmZpbGVfZXhpc3RzX3AoKS4gVGhpcyBmdW5jdGlvbiwgaW4KdHVybiwgY2FsbHMg RmV4cGFuZF9maWxlX25hbWUoKS4gVGhpcyBmdW5jdGlvbiB3aWxsIHVzZSB0aGUgcm9vdApkaXJl Y3RvcnkgYXMgYGRlZmF1bHRfZGlyZWN0b3J5JyBhcyBhIGZhbGxiYWNrLgoKR2V0dGluZyB0aGUg cm9vdCBkaXJlY3RvcnkgcmVxdWlyZXMgcmVhZGluZyB0aGUgJGVtYWNzX2RpciBlbnZpcm9ubWVu dAp2YXJpYWJsZS4gIFRoaXMgaXMgc2V0dXAgbGF0ZXIgaW4gdGhlIGluaXRpYWxpemF0aW9uIHBy b2Nlc3MuIFRoaXMKY2F1c2VkIGEgY3Jhc2guCgpGZXhwYW5kX2ZpbGVfbmFtZSgpIHdhcyB0cnlp bmcgdG8gb2J0YWluIHRoZSByb290IGRpcmVjdG9yeSBldmVuIHdoZW4KaXQgd2FzIG5vdCBuZWNl c3NhcnkgYmVjYXVzZSBgZGVmYXVsdC1kaXJlY3RvcnknIHdhcyBub3QgbmlsLgoKSXQgdHVybnMg b3V0IHRoYXQgdGhlIGR1bXAgbG9hZGluZyBwcm9jZXNzIGRvZXMgbm90IHNldApgZGVmYXVsdC1k aXJlY3RvcnknIHRvIG5pbCwgdGhlcmVmb3JlIEZleHBhbmRfZmlsZV9uYW1lKCkgZG9lcyBub3QK bmVlZCB0byBmaW5kIG91dCB0aGUgcm9vdCBkaXJlY3RvcnkgYW5kIHdlIGF2b2lkIHJlYWRpbmcg YW4KZW52aXJvbm1lbnQgdmFyaWFibGUgdGhhdCBpcyBub3Qgc2V0IHlldC4KCldpdGggdGhpcyBw YXRjaCB3ZSBhdm9pZCBjYWxsaW5nIGZpbGVuYW1lX2Zyb21fYW5zaSgpIHRvbyBlYXJseSAoSXQg aXMKbm90IHRoZSByZWFzb24gd2h5IEVtYWNzIGNyYXNoZWQsIGJ1dCBpdCBpcyBzdGlsbCBpbXBv cnRhbnQgdG8gY2FsbCBpdAphZnRlciBpdCBoYXMgYmVlbiBzZXR1cCBwcm9wZXJseS4KCiogc3Jj L2ZpbGVpby5jOiBJbnRyb2R1Y2UgZnVuY3Rpb24gZW1hY3Nfcm9vdF9kaXIoKS4gUmVmYWN0b3IK YGV4cGFuZC1maWxlLW5hbWVgIHRvIHVzZSBpdC4KKiBzcmMvbGlzcC5oOiBTZXBhcmF0ZSBlbWFj c19yb290X2RpcigpIGludG8gZG9zX2VtYWNzX3Jvb3RfZGlyKCkgYW5kCnczMl9lbWFjc19yb290 X2RpcigpLgoqIHNyYy9tc2Rvcy5jOiBSZW5hbWUgZW1hY3Nfcm9vdF9kaXIoKSB0byBkb3NfZW1h Y3Nfcm9vdF9kaXIoKS4KKiBzcmMvdzMyLmM6IFJlbmFtZSBlbWFjc19yb290X2RpcigpIHRvIHcz Ml9lbWFjc19yb290X2RpcigpLgotLS0KIHNyYy9maWxlaW8uYyB8IDQ1ICsrKysrKysrKysrKysr KysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLQogc3JjL2xpc3AuaCAgIHwgMTEgKysrKysr Ky0tLS0KIHNyYy9tc2Rvcy5jICB8ICAyICstCiBzcmMvdzMyLmMgICAgfCAgMiArLQogNCBmaWxl cyBjaGFuZ2VkLCAzNSBpbnNlcnRpb25zKCspLCAyNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9zcmMvZmlsZWlvLmMgYi9zcmMvZmlsZWlvLmMKaW5kZXggMmYxZDJmODI0My4uMTEzNzRhYzU2 ZCAxMDA2NDQKLS0tIGEvc3JjL2ZpbGVpby5jCisrKyBiL3NyYy9maWxlaW8uYwpAQCAtNzgxLDYg Kzc4MSwzMCBAQCB1c2VyX2hvbWVkaXIgKGNoYXIgY29uc3QgKm5hbWUpCiAgIHJldHVybiBwdy0+ cHdfZGlyOwogfQogCisvKiBBcyBhIGxhc3QgcmVzb3J0LCB3ZSBtYXkgaGF2ZSB0byB1c2UgdGhl IHJvb3QgYXMKKyAgIGRlZmF1bHRfZGlyZWN0b3J5IGluIGBleHBhbmQtZmlsZS1uYW1lJy4KKwor ICAgIi8iIGlzIG5vdCBjb25zaWRlcmVkIGEgcm9vdCBkaXJlY3Rvcnkgb24gRE9TX05ULCBzbyB1 c2luZyBpdAorICAgYXMgZGVmYXVsdF9kaXJlY3RvcnkgY2F1c2VzIGFuIGluZmluaXRlIHJlY3Vy c2lvbiBpbiwgZS5nLiwKKyAgIHRoZSBmb2xsb3dpbmc6CisKKyAgIChsZXQgKGRlZmF1bHQtZGly ZWN0b3J5KQorICAgICAgICAgIChleHBhbmQtZmlsZS1uYW1lICJhIikpCisKKyAgIFRvIGF2b2lk IHRoaXMsIHdlIHVzZSB0aGUgcm9vdCBvZiB0aGUgY3VycmVudCBkcml2ZS4gKi8KKworc3RhdGlj IExpc3BfT2JqZWN0CitlbWFjc19yb290X2RpciAodm9pZCkKK3sKKyNpZmRlZiBET1MKKyAgcmV0 dXJuIGJ1aWxkX3N0cmluZyAoZG9zX2VtYWNzX3Jvb3RfZGlyICgpKTsKKyNlbGlmIGRlZmluZWQg KFdJTkRPV1NOVCkKKyAgcmV0dXJuIGJ1aWxkX3N0cmluZyAodzMyX2VtYWNzX3Jvb3RfZGlyICgp KTsKKyNlbHNlCisgIHJldHVybiBidWlsZF9zdHJpbmcgKCIvIik7CisjZW5kaWYKK30KKwogREVG VU4gKCJleHBhbmQtZmlsZS1uYW1lIiwgRmV4cGFuZF9maWxlX25hbWUsIFNleHBhbmRfZmlsZV9u YW1lLCAxLCAyLCAwLAogICAgICAgIGRvYzogLyogQ29udmVydCBmaWxlbmFtZSBOQU1FIHRvIGFi c29sdXRlLCBhbmQgY2Fub25pY2FsaXplIGl0LgogU2Vjb25kIGFyZyBERUZBVUxULURJUkVDVE9S WSBpcyBkaXJlY3RvcnkgdG8gc3RhcnQgd2l0aCBpZiBOQU1FIGlzIHJlbGF0aXZlCkBAIC04NTAs MjMgKzg3NCw2IEBAIERFRlVOICgiZXhwYW5kLWZpbGUtbmFtZSIsIEZleHBhbmRfZmlsZV9uYW1l LCBTZXhwYW5kX2ZpbGVfbmFtZSwgMSwgMiwgMCwKICAgICAgIGVycm9yICgiSW52YWxpZCBoYW5k bGVyIGluIGBmaWxlLW5hbWUtaGFuZGxlci1hbGlzdCciKTsKICAgICB9CiAKLSAgLyogQXMgYSBs YXN0IHJlc29ydCwgd2UgbWF5IGhhdmUgdG8gdXNlIHRoZSByb290IGFzCi0gICAgIGRlZmF1bHRf ZGlyZWN0b3J5IGJlbG93LiAgKi8KLSAgTGlzcF9PYmplY3Qgcm9vdDsKLSNpZmRlZiBET1NfTlQK LSAgICAgIC8qICIvIiBpcyBub3QgY29uc2lkZXJlZCBhIHJvb3QgZGlyZWN0b3J5IG9uIERPU19O VCwgc28gdXNpbmcgaXQKLQkgYXMgZGVmYXVsdF9kaXJlY3RvcnkgY2F1c2VzIGFuIGluZmluaXRl IHJlY3Vyc2lvbiBpbiwgZS5nLiwKLQkgdGhlIGZvbGxvd2luZzoKLQotICAgICAgICAgICAgKGxl dCAoZGVmYXVsdC1kaXJlY3RvcnkpCi0JICAgICAgKGV4cGFuZC1maWxlLW5hbWUgImEiKSkKLQot CSBUbyBhdm9pZCB0aGlzLCB3ZSB1c2UgdGhlIHJvb3Qgb2YgdGhlIGN1cnJlbnQgZHJpdmUuICAq LwotICAgICAgcm9vdCA9IGJ1aWxkX3N0cmluZyAoZW1hY3Nfcm9vdF9kaXIgKCkpOwotI2Vsc2UK LSAgICAgIHJvb3QgPSBidWlsZF9zdHJpbmcgKCIvIik7Ci0jZW5kaWYKLQogICAvKiBVc2UgdGhl IGJ1ZmZlcidzIGRlZmF1bHQtZGlyZWN0b3J5IGlmIERFRkFVTFRfRElSRUNUT1JZIGlzIG9taXR0 ZWQuICAqLwogICBpZiAoTklMUCAoZGVmYXVsdF9kaXJlY3RvcnkpKQogICAgIHsKQEAgLTg5MSwx MyArODk4LDEzIEBAIERFRlVOICgiZXhwYW5kLWZpbGUtbmFtZSIsIEZleHBhbmRfZmlsZV9uYW1l LCBTZXhwYW5kX2ZpbGVfbmFtZSwgMSwgMiwgMCwKIAkgICAgICBMaXNwX09iamVjdCBhYnNkaXIK IAkJPSBTVFJJTkdQIChWaW52b2NhdGlvbl9kaXJlY3RvcnkpCiAJCSYmIGZpbGVfbmFtZV9hYnNv bHV0ZV9ub190aWxkZV9wIChWaW52b2NhdGlvbl9kaXJlY3RvcnkpCi0JCT8gVmludm9jYXRpb25f ZGlyZWN0b3J5IDogcm9vdDsKKwkJPyBWaW52b2NhdGlvbl9kaXJlY3RvcnkgOiBlbWFjc19yb290 X2RpciAoKTsKIAkgICAgICBkZWZhdWx0X2RpcmVjdG9yeSA9IEZleHBhbmRfZmlsZV9uYW1lIChk aXIsIGFic2Rpcik7CiAJICAgIH0KIAl9CiAgICAgfQogICBpZiAoISBTVFJJTkdQIChkZWZhdWx0 X2RpcmVjdG9yeSkpCi0gICAgZGVmYXVsdF9kaXJlY3RvcnkgPSByb290OworICAgIGRlZmF1bHRf ZGlyZWN0b3J5ID0gZW1hY3Nfcm9vdF9kaXIgKCk7CiAKICAgaGFuZGxlciA9IEZmaW5kX2ZpbGVf bmFtZV9oYW5kbGVyIChkZWZhdWx0X2RpcmVjdG9yeSwgUWV4cGFuZF9maWxlX25hbWUpOwogICBp ZiAoIU5JTFAgKGhhbmRsZXIpKQpkaWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNwLmgK aW5kZXggNWY5MjFkNThkYy4uNjkzNmJiYmIzOSAxMDA2NDQKLS0tIGEvc3JjL2xpc3AuaAorKysg Yi9zcmMvbGlzcC5oCkBAIC00NzQ5LDEwICs0NzQ5LDEzIEBAIG1heWJlX2Rpc2FibGVfYWRkcmVz c19yYW5kb21pemF0aW9uIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiBleHRlcm4gdm9pZCBtYWxs b2NfcHJvYmUgKHNpemVfdCk7CiBleHRlcm4gdm9pZCBzeW1zX29mX3Byb2ZpbGVyICh2b2lkKTsK IAotI2lmZGVmIERPU19OVAotLyogRGVmaW5lZCBpbiBtc2Rvcy5jLCB3MzIuYy4gICovCi1leHRl cm4gY2hhciAqZW1hY3Nfcm9vdF9kaXIgKHZvaWQpOwotI2VuZGlmIC8qIERPU19OVCAqLworI2lm ZGVmIE1TRE9TCisvKiBEZWZpbmVkIGluIG1zZG9zLmMuICAqLworZXh0ZXJuIGNoYXIgKmRvc19l bWFjc19yb290X2RpciAodm9pZCk7CisjZWxpZiBkZWZpbmVkIChXSU5ET1dTTlQpCisvKiBEZWZp bmVkIGluIHczMi5jLiAgKi8KK2V4dGVybiBjaGFyICp3MzJfZW1hY3Nfcm9vdF9kaXIgKHZvaWQp OworI2VuZGlmIC8qIE1TRE9TICovCiAKICNpZmRlZiBIQVZFX05BVElWRV9DT01QCiBJTkxJTkUg Ym9vbApkaWZmIC0tZ2l0IGEvc3JjL21zZG9zLmMgYi9zcmMvbXNkb3MuYwppbmRleCBiNWYwNmM5 OWMzLi4wODI3Y2M5NmNkIDEwMDY0NAotLS0gYS9zcmMvbXNkb3MuYworKysgYi9zcmMvbXNkb3Mu YwpAQCAtMzM1MCw3ICszMzUwLDcgQEAgZ2V0ZGVmZGlyIChpbnQgZHJpdmUsIGNoYXIgKmRzdCkK IH0KIAogY2hhciAqCi1lbWFjc19yb290X2RpciAodm9pZCkKK2Rvc19lbWFjc19yb290X2RpciAo dm9pZCkKIHsKICAgc3RhdGljIGNoYXIgcm9vdF9kaXJbNF07CiAKZGlmZiAtLWdpdCBhL3NyYy93 MzIuYyBiL3NyYy93MzIuYwppbmRleCAzZTcxZDBkMzgzLi5iY2U4MzcxMTY0IDEwMDY0NAotLS0g YS9zcmMvdzMyLmMKKysrIGIvc3JjL3czMi5jCkBAIC0zMTQ3LDcgKzMxNDcsNyBAQCAjZGVmaW5l IFNFVF9FTlZfQlVGX1NJWkUgKDQgKiBNQVhfUEFUSCkJLyogdG8gY292ZXIgRU1BQ1NMT0FEUEFU SCAqLwogLyogQ2FsbGVkIGZyb20gZXhwYW5kLWZpbGUtbmFtZSB3aGVuIGRlZmF1bHQtZGlyZWN0 b3J5IGlzIG5vdCBhIHN0cmluZy4gICovCiAKIGNoYXIgKgotZW1hY3Nfcm9vdF9kaXIgKHZvaWQp Cit3MzJfZW1hY3Nfcm9vdF9kaXIgKHZvaWQpCiB7CiAgIHN0YXRpYyBjaGFyIHJvb3RfZGlyW01B WF9VVEY4X1BBVEhdOwogICBjb25zdCBjaGFyICpwOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000df104505a6beaf18-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 08:12:54 2020 Received: (at 41242) by debbugs.gnu.org; 29 May 2020 12:12:54 +0000 Received: from localhost ([127.0.0.1]:54048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jedsc-000176-51 for submit@debbugs.gnu.org; Fri, 29 May 2020 08:12:54 -0400 Received: from mx.sdf.org ([205.166.94.20]:52949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jedsa-00016t-DF for 41242@debbugs.gnu.org; Fri, 29 May 2020 08:12:52 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04TCCnWo005567 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 29 May 2020 12:12:49 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04TCCnxY009324; Fri, 29 May 2020 12:12:49 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Fri, 29 May 2020 12:12:49 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Thu, 28 May 2020 21:39:55 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi, > > I have taken your comments into consideration and updated the patch. Hi thanks, looks more clear to me. question: what if instead of using Ffile_exists we just use fopen to check if the file exists in dump_do_dump_relocation? I think the origin of "the trouble" is just there while checking if a file exists, the path in discussion should be already absolute by construction so I suspect we do not need Fexpand_file to come into play. Haven't tried, but if it works looks to me cleaner then entering in logic where not everything is initialized. It's true that now you have verified that with your patch the execution path does not involve variables to be initialized, but the logic could change in the future. What do you think? Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 09:54:44 2020 Received: (at 41242) by debbugs.gnu.org; 29 May 2020 13:54:44 +0000 Received: from localhost ([127.0.0.1]:54209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefT9-0003f0-P0 for submit@debbugs.gnu.org; Fri, 29 May 2020 09:54:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefSv-0003eX-Ab for 41242@debbugs.gnu.org; Fri, 29 May 2020 09:54:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39208) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jefSn-0003mw-KX; Fri, 29 May 2020 09:54:21 -0400 Received: from [176.228.60.248] (port=3935 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jefSm-0000vq-Ty; Fri, 29 May 2020 09:54:21 -0400 Date: Fri, 29 May 2020 16:54:15 +0300 Message-Id: <83v9ken8xk.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Fri, 29 May 2020 12:12:49 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: 41242@debbugs.gnu.org, Eli Zaretskii > Date: Fri, 29 May 2020 12:12:49 +0000 > > question: what if instead of using Ffile_exists we just use fopen to > check if the file exists in dump_do_dump_relocation? > > I think the origin of "the trouble" is just there while checking if a > file exists, the path in discussion should be already absolute by > construction so I suspect we do not need Fexpand_file to come into play. Will that work if the files were moved? From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 10:26:42 2020 Received: (at 41242) by debbugs.gnu.org; 29 May 2020 14:26:42 +0000 Received: from localhost ([127.0.0.1]:55742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefy5-0000j8-Om for submit@debbugs.gnu.org; Fri, 29 May 2020 10:26:41 -0400 Received: from mx.sdf.org ([205.166.94.20]:52843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefy4-0000iy-Mf for 41242@debbugs.gnu.org; Fri, 29 May 2020 10:26:41 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04TEQbfu003293 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 29 May 2020 14:26:38 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04TEQbIi007037; Fri, 29 May 2020 14:26:37 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> <83v9ken8xk.fsf@gnu.org> Date: Fri, 29 May 2020 14:26:37 +0000 In-Reply-To: <83v9ken8xk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 May 2020 16:54:15 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> From: Andrea Corallo >> Cc: 41242@debbugs.gnu.org, Eli Zaretskii >> Date: Fri, 29 May 2020 12:12:49 +0000 >> >> question: what if instead of using Ffile_exists we just use fopen to >> check if the file exists in dump_do_dump_relocation? >> >> I think the origin of "the trouble" is just there while checking if a >> file exists, the path in discussion should be already absolute by >> construction so I suspect we do not need Fexpand_file to come into play. > > Will that work if the files were moved? I think so yes, the absolute path under discussion is generated on purpose using Vinvocation_directory as follow: pdumper.c:5304 ===== if (installation_state == UNKNOWN) /* Check just once if is a local build or Emacs got installed. */ installation_state = NILP (Ffile_exists_p (concat2 (Vinvocation_directory, XCAR (comp_u->file)))) ? LOCAL_BUILD : INSTALLED; ==== Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 06:51:36 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 10:51:36 +0000 Received: from localhost ([127.0.0.1]:56981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jez5T-0003qn-TS for submit@debbugs.gnu.org; Sat, 30 May 2020 06:51:36 -0400 Received: from mx.sdf.org ([205.166.94.20]:64250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jez5S-0003qe-BJ for 41242@debbugs.gnu.org; Sat, 30 May 2020 06:51:35 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04UApVXf012059 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 30 May 2020 10:51:31 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04UApVeE015304; Sat, 30 May 2020 10:51:31 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Sat, 30 May 2020 10:51:31 +0000 In-Reply-To: (Andrea Corallo's message of "Fri, 29 May 2020 12:12:49 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Andrea Corallo writes: > Nicolas B=C3=A9rtolo writes: > >> Hi, >> >> I have taken your comments into consideration and updated the patch. > > Hi thanks, looks more clear to me. > > question: what if instead of using Ffile_exists we just use fopen to > check if the file exists in dump_do_dump_relocation? > > I think the origin of "the trouble" is just there while checking if a > file exists, the path in discussion should be already absolute by > construction so I suspect we do not need Fexpand_file to come into play. > > Haven't tried, but if it works looks to me cleaner then entering in > logic where not everything is initialized. It's true that now you have > verified that with your patch the execution path does not involve > variables to be initialized, but the logic could change in the future. > > What do you think? > > Thanks > > Andrea I've pushed 15c121ee0b "* Avoid calling Ffile_exists_p too early" implementing the discussed idea. Should do the job in Windows too, please give it a try. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 09:06:54 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 13:06:54 +0000 Received: from localhost ([127.0.0.1]:57142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1CP-0000pc-Ur for submit@debbugs.gnu.org; Sat, 30 May 2020 09:06:54 -0400 Received: from mail-ot1-f43.google.com ([209.85.210.43]:42953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1CO-0000pP-JY for 41242@debbugs.gnu.org; Sat, 30 May 2020 09:06:52 -0400 Received: by mail-ot1-f43.google.com with SMTP id z3so4144369otp.9 for <41242@debbugs.gnu.org>; Sat, 30 May 2020 06:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xwQ5pBXi6R15urfb13WOMoIy9a91hIiwI9Ho7ZRv4dw=; b=l/W4u39BPn/veMMQcU75EVEWsd7XpSDO8r+P4r+1mt/WIiTAm9a0Sog4pIaKK9kqmx zy0rgNLK7Pmi27eEtMBQvWLphOslv/zYD5tenkQgRlF+xgnJsjmPfTtS2ecFoT5T4bCk VgUzML4srCkx1hR2usbdixPtsCJsyYQZjI0B/v4RnJECOl0BrmYKD3uDvPUeP68JhoTY qX+p8ItIGdYIjun9vKX1dE3c2GfL263R04yBz9bJ+vwMifLxhtFL5M30zjO6NUqkUlQM rQMkdWj5VEV8Wo/VG9TQEiOBjI8UIe6GeZuolJdmLV64wraB1C0vPASPdoXJRTsCD9xR Iw1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xwQ5pBXi6R15urfb13WOMoIy9a91hIiwI9Ho7ZRv4dw=; b=lmlNRIABo0X/h8l5/GAts2toCTkNCtfvKFYL6BkxBY0gpRxze6He22+GeG2FnWXBNu CKpfQtKkiZbV5ZXf8Du46ieW5J1DJtj3wuA5xOU0+JthJTdcLM06QqocLPRIUJ5+zSLE DN5nrTcC7mVlgmFV1PVy9IOFK8zJ4i8YTekKcK1+iQ/VoUzmS9MYYhG9sqZehoFZ6jNb 3xI9gk0sYsThaPQrC2gl964YJ0mUqOeAfnZobpSU3vBXQMiDANU6t4G3mDhyr2kkbdwE PAmqEN4xwcLKoS5Ex2GBakxri66o14GwPX1XviCaAVMtb8ECwtV22WnY3Rr04oAlZr+5 /MxA== X-Gm-Message-State: AOAM532yvQZVbOjEk4LlMOGor7463tBJ301SEBEbs+r67scwfzLobCIR OrpwshOvVsp7u+LtKFvSSdNqwzUOxnbB+wk4HyaJMpmzRKU= X-Google-Smtp-Source: ABdhPJyh2t+iN54hzPKLOvmCJmAQuJHBRsCQa1/m+u1a/idCpC8f2Gckhu2YU5/tvug4Wd3ICx1lxRsaQ5dPOo0Ttrg= X-Received: by 2002:a9d:4c19:: with SMTP id l25mr7633552otf.193.1590844006906; Sat, 30 May 2020 06:06:46 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 30 May 2020 10:06:34 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > I've pushed 15c121ee0b "* Avoid calling Ffile_exists_p too early" > implementing the discussed idea. > Should do the job in Windows too, please give it a try. It works well, thank you. Last night I implemented a very similar patch, but I didn't send it because it was too late. You beat me to it. Nico From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 09:24:16 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 13:24:16 +0000 Received: from localhost ([127.0.0.1]:57167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1TE-0001Fo-I6 for submit@debbugs.gnu.org; Sat, 30 May 2020 09:24:16 -0400 Received: from mail-oo1-f51.google.com ([209.85.161.51]:43157) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf1TC-0001Fa-K0 for 41242@debbugs.gnu.org; Sat, 30 May 2020 09:24:15 -0400 Received: by mail-oo1-f51.google.com with SMTP id u190so480984ooa.10 for <41242@debbugs.gnu.org>; Sat, 30 May 2020 06:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/vqzOGpZ3ozT7wnloLyz0QR1NGCSgQIN6WByvTySB4I=; b=moblqQXlaVIdwtzV5dpV5WRw9dnxT4NccpG0Xf8iLPgs9wWLk7hB9LDG5fmRo0eudr 4eKB047cyFAAn+8i86u/7JDHHXXXtzvl0zTmIXy06zhKmZlJz//JgYzcWyu/5v1XLVS9 D0S9nhEIARo8MPD8B/8PEYDvxUi8jU6YVejaEydVp4bHfx3w73oRLf5E0HBfe/TiVd+8 TrDm22Z+pquJeq89AAN2OiNIlz1HN0xTrrFn77gwS/asj786UaGQjZFJh00HprQVYMNc 5qJ+KVNuwferlJYDHZBadC6KzWfW3YF6zGLA0H/X+D+Ssvlw7ek9z71nk5JxGBpCsG/C X1kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/vqzOGpZ3ozT7wnloLyz0QR1NGCSgQIN6WByvTySB4I=; b=MopHgrXnRu4rJhZSJp5o9umj9aYpYnVwpaWMb4LtpPOn0IkLq1Cs7C8MNQJ1CqKiiY c0R/HUhe8624YzalBo5yGGp7vEQ5ETbk0vhwQQBK5jxtUSnuabYh5oPJGGN/aASeP6LF 2h9/4FW4z1NRp2zn4DdFupeLGnmw6Suv6gzuOq8eFBs5CCvgvlB2N5wScLKFpGI7ETCz C10Wfl3wedshvmCQs0zayWRPkeaiIIbLGOt4ZyzWkHil/RZGpSnpKWz9RuPVjHEeT5U/ BAAiQS6PnAUeMeVk4uJcGaiZrL5cFGdy6ShV3ibuztlNeph2c3bhlg14y4vG5qISatTT pNuQ== X-Gm-Message-State: AOAM532OgR0ABRcuk2HEBfUYaKUJG9dvRs5pp9y/DUAB7F7YNFZ7Yqln Tl0ElmzNiUE3HUfoEu3T+oQ/oH1IHO+ANk2tWp0= X-Google-Smtp-Source: ABdhPJyYDzR93Bv2PjfuquiUFVdAXBRKt76SC/6GT1pMKdFPYIvQStW6ZEGDci+UKZCUXTuQLksmBctexBV6B+3yMsc= X-Received: by 2002:a4a:bf14:: with SMTP id r20mr10614755oop.18.1590845048900; Sat, 30 May 2020 06:24:08 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 30 May 2020 10:23:55 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: multipart/mixed; boundary="00000000000008b03c05a6dd7a95" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --00000000000008b03c05a6dd7a95 Content-Type: text/plain; charset="UTF-8" I have found a few bugs in Windows. Patches attached (they are in my repo too). - It is still a good idea to avoid the call to getenv("emacs_dir"), if only for performance reasons. - We can't use "gensym" for register_native_comp_unit() because the dynamic library may not have been loaded yet when loading a dump file. - Commit `f5dceed09a8234548d5b3acb76d443569533cab9` "* lisp/loadup.el: Use new 'native-comp-available-p'." causes load_gccjit_if_necessary() to be called in temacs. This didn't work because because term/w32-win.el had not been loaded yet. In particular, we need `dynamic-library-alist` to be defined to know the name of the libgccjit DLL. I have defined this in syms_of_emacs(). This definition should be active only while dumping. - This last bug is kinda confusing. I'm not sure about my diagnosis. The list `delayed_comp_unit_disposal_list` has nodes allocated with xmalloc(). It seems that these blocks allocated with xmalloc() get GC'd or they get corrupted somehow and thus they don't survive until Emacs is about to close, which is when we need the list. I solved it by allocating the data and nodes with HeapAlloc(). Thanks, Nico. --00000000000008b03c05a6dd7a95 Content-Type: application/octet-stream; name="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Disposition: attachment; filename="0001-Determine-the-emacs-root-dir-only-when-necessary.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kato208n0 RnJvbSA0MmU1ZDM0ZjlmMTdlYzg1ZGEzNzZmYjZjMTg1NjliYTFjYzM1M2Q0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAyNSBNYXkgMjAyMCAxNzo1 NToyMyAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMS80XSBEZXRlcm1pbmUgdGhlIGVtYWNzIHJvb3Qg ZGlyIG9ubHkgd2hlbiBuZWNlc3NhcnkuCgpGZXhwYW5kX2ZpbGVfbmFtZSgpIHRyaWVzIHRvIG9i dGFpbiB0aGUgcm9vdCBkaXJlY3RvcnkgZXZlbiB3aGVuIGl0CmlzIG5vdCBuZWNlc3NhcnkgYmVj YXVzZSBgZGVmYXVsdC1kaXJlY3RvcnknIGlzIG5vdCBuaWwuCgpBdm9pZCBhIGNhbGwgdG8gZ2V0 ZW52ICgpIHVubGVzcyBpdCdzIG5lY2Vzc2FyeS4KCiogc3JjL2ZpbGVpby5jOiBJbnRyb2R1Y2Ug ZnVuY3Rpb24gZW1hY3Nfcm9vdF9kaXIoKS4gUmVmYWN0b3IKYGV4cGFuZC1maWxlLW5hbWVgIHRv IHVzZSBpdC4KKiBzcmMvbGlzcC5oOiBTZXBhcmF0ZSBlbWFjc19yb290X2RpcigpIGludG8gZG9z X2VtYWNzX3Jvb3RfZGlyKCkgYW5kCnczMl9lbWFjc19yb290X2RpcigpLgoqIHNyYy9tc2Rvcy5j OiBSZW5hbWUgZW1hY3Nfcm9vdF9kaXIoKSB0byBkb3NfZW1hY3Nfcm9vdF9kaXIoKS4KKiBzcmMv dzMyLmM6IFJlbmFtZSBlbWFjc19yb290X2RpcigpIHRvIHczMl9lbWFjc19yb290X2RpcigpLgot LS0KIHNyYy9maWxlaW8uYyB8IDQ1ICsrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0t LS0tLS0tLS0tLQogc3JjL2xpc3AuaCAgIHwgMTEgKysrKysrKy0tLS0KIHNyYy9tc2Rvcy5jICB8 ICAyICstCiBzcmMvdzMyLmMgICAgfCAgMiArLQogNCBmaWxlcyBjaGFuZ2VkLCAzNSBpbnNlcnRp b25zKCspLCAyNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvZmlsZWlvLmMgYi9zcmMv ZmlsZWlvLmMKaW5kZXggMmYxZDJmODI0My4uMTEzNzRhYzU2ZCAxMDA2NDQKLS0tIGEvc3JjL2Zp bGVpby5jCisrKyBiL3NyYy9maWxlaW8uYwpAQCAtNzgxLDYgKzc4MSwzMCBAQCB1c2VyX2hvbWVk aXIgKGNoYXIgY29uc3QgKm5hbWUpCiAgIHJldHVybiBwdy0+cHdfZGlyOwogfQogCisvKiBBcyBh IGxhc3QgcmVzb3J0LCB3ZSBtYXkgaGF2ZSB0byB1c2UgdGhlIHJvb3QgYXMKKyAgIGRlZmF1bHRf ZGlyZWN0b3J5IGluIGBleHBhbmQtZmlsZS1uYW1lJy4KKworICAgIi8iIGlzIG5vdCBjb25zaWRl cmVkIGEgcm9vdCBkaXJlY3Rvcnkgb24gRE9TX05ULCBzbyB1c2luZyBpdAorICAgYXMgZGVmYXVs dF9kaXJlY3RvcnkgY2F1c2VzIGFuIGluZmluaXRlIHJlY3Vyc2lvbiBpbiwgZS5nLiwKKyAgIHRo ZSBmb2xsb3dpbmc6CisKKyAgIChsZXQgKGRlZmF1bHQtZGlyZWN0b3J5KQorICAgICAgICAgIChl eHBhbmQtZmlsZS1uYW1lICJhIikpCisKKyAgIFRvIGF2b2lkIHRoaXMsIHdlIHVzZSB0aGUgcm9v dCBvZiB0aGUgY3VycmVudCBkcml2ZS4gKi8KKworc3RhdGljIExpc3BfT2JqZWN0CitlbWFjc19y b290X2RpciAodm9pZCkKK3sKKyNpZmRlZiBET1MKKyAgcmV0dXJuIGJ1aWxkX3N0cmluZyAoZG9z X2VtYWNzX3Jvb3RfZGlyICgpKTsKKyNlbGlmIGRlZmluZWQgKFdJTkRPV1NOVCkKKyAgcmV0dXJu IGJ1aWxkX3N0cmluZyAodzMyX2VtYWNzX3Jvb3RfZGlyICgpKTsKKyNlbHNlCisgIHJldHVybiBi dWlsZF9zdHJpbmcgKCIvIik7CisjZW5kaWYKK30KKwogREVGVU4gKCJleHBhbmQtZmlsZS1uYW1l IiwgRmV4cGFuZF9maWxlX25hbWUsIFNleHBhbmRfZmlsZV9uYW1lLCAxLCAyLCAwLAogICAgICAg IGRvYzogLyogQ29udmVydCBmaWxlbmFtZSBOQU1FIHRvIGFic29sdXRlLCBhbmQgY2Fub25pY2Fs aXplIGl0LgogU2Vjb25kIGFyZyBERUZBVUxULURJUkVDVE9SWSBpcyBkaXJlY3RvcnkgdG8gc3Rh cnQgd2l0aCBpZiBOQU1FIGlzIHJlbGF0aXZlCkBAIC04NTAsMjMgKzg3NCw2IEBAIERFRlVOICgi ZXhwYW5kLWZpbGUtbmFtZSIsIEZleHBhbmRfZmlsZV9uYW1lLCBTZXhwYW5kX2ZpbGVfbmFtZSwg MSwgMiwgMCwKICAgICAgIGVycm9yICgiSW52YWxpZCBoYW5kbGVyIGluIGBmaWxlLW5hbWUtaGFu ZGxlci1hbGlzdCciKTsKICAgICB9CiAKLSAgLyogQXMgYSBsYXN0IHJlc29ydCwgd2UgbWF5IGhh dmUgdG8gdXNlIHRoZSByb290IGFzCi0gICAgIGRlZmF1bHRfZGlyZWN0b3J5IGJlbG93LiAgKi8K LSAgTGlzcF9PYmplY3Qgcm9vdDsKLSNpZmRlZiBET1NfTlQKLSAgICAgIC8qICIvIiBpcyBub3Qg Y29uc2lkZXJlZCBhIHJvb3QgZGlyZWN0b3J5IG9uIERPU19OVCwgc28gdXNpbmcgaXQKLQkgYXMg ZGVmYXVsdF9kaXJlY3RvcnkgY2F1c2VzIGFuIGluZmluaXRlIHJlY3Vyc2lvbiBpbiwgZS5nLiwK LQkgdGhlIGZvbGxvd2luZzoKLQotICAgICAgICAgICAgKGxldCAoZGVmYXVsdC1kaXJlY3Rvcnkp Ci0JICAgICAgKGV4cGFuZC1maWxlLW5hbWUgImEiKSkKLQotCSBUbyBhdm9pZCB0aGlzLCB3ZSB1 c2UgdGhlIHJvb3Qgb2YgdGhlIGN1cnJlbnQgZHJpdmUuICAqLwotICAgICAgcm9vdCA9IGJ1aWxk X3N0cmluZyAoZW1hY3Nfcm9vdF9kaXIgKCkpOwotI2Vsc2UKLSAgICAgIHJvb3QgPSBidWlsZF9z dHJpbmcgKCIvIik7Ci0jZW5kaWYKLQogICAvKiBVc2UgdGhlIGJ1ZmZlcidzIGRlZmF1bHQtZGly ZWN0b3J5IGlmIERFRkFVTFRfRElSRUNUT1JZIGlzIG9taXR0ZWQuICAqLwogICBpZiAoTklMUCAo ZGVmYXVsdF9kaXJlY3RvcnkpKQogICAgIHsKQEAgLTg5MSwxMyArODk4LDEzIEBAIERFRlVOICgi ZXhwYW5kLWZpbGUtbmFtZSIsIEZleHBhbmRfZmlsZV9uYW1lLCBTZXhwYW5kX2ZpbGVfbmFtZSwg MSwgMiwgMCwKIAkgICAgICBMaXNwX09iamVjdCBhYnNkaXIKIAkJPSBTVFJJTkdQIChWaW52b2Nh dGlvbl9kaXJlY3RvcnkpCiAJCSYmIGZpbGVfbmFtZV9hYnNvbHV0ZV9ub190aWxkZV9wIChWaW52 b2NhdGlvbl9kaXJlY3RvcnkpCi0JCT8gVmludm9jYXRpb25fZGlyZWN0b3J5IDogcm9vdDsKKwkJ PyBWaW52b2NhdGlvbl9kaXJlY3RvcnkgOiBlbWFjc19yb290X2RpciAoKTsKIAkgICAgICBkZWZh dWx0X2RpcmVjdG9yeSA9IEZleHBhbmRfZmlsZV9uYW1lIChkaXIsIGFic2Rpcik7CiAJICAgIH0K IAl9CiAgICAgfQogICBpZiAoISBTVFJJTkdQIChkZWZhdWx0X2RpcmVjdG9yeSkpCi0gICAgZGVm YXVsdF9kaXJlY3RvcnkgPSByb290OworICAgIGRlZmF1bHRfZGlyZWN0b3J5ID0gZW1hY3Nfcm9v dF9kaXIgKCk7CiAKICAgaGFuZGxlciA9IEZmaW5kX2ZpbGVfbmFtZV9oYW5kbGVyIChkZWZhdWx0 X2RpcmVjdG9yeSwgUWV4cGFuZF9maWxlX25hbWUpOwogICBpZiAoIU5JTFAgKGhhbmRsZXIpKQpk aWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNwLmgKaW5kZXggMjNiMTA1ZTU1MC4uOTcw NGU3OGNmNCAxMDA2NDQKLS0tIGEvc3JjL2xpc3AuaAorKysgYi9zcmMvbGlzcC5oCkBAIC00NzQ2 LDEwICs0NzQ2LDEzIEBAIG1heWJlX2Rpc2FibGVfYWRkcmVzc19yYW5kb21pemF0aW9uIChpbnQg YXJnYywgY2hhciAqKmFyZ3YpCiBleHRlcm4gdm9pZCBtYWxsb2NfcHJvYmUgKHNpemVfdCk7CiBl eHRlcm4gdm9pZCBzeW1zX29mX3Byb2ZpbGVyICh2b2lkKTsKIAotI2lmZGVmIERPU19OVAotLyog RGVmaW5lZCBpbiBtc2Rvcy5jLCB3MzIuYy4gICovCi1leHRlcm4gY2hhciAqZW1hY3Nfcm9vdF9k aXIgKHZvaWQpOwotI2VuZGlmIC8qIERPU19OVCAqLworI2lmZGVmIE1TRE9TCisvKiBEZWZpbmVk IGluIG1zZG9zLmMuICAqLworZXh0ZXJuIGNoYXIgKmRvc19lbWFjc19yb290X2RpciAodm9pZCk7 CisjZWxpZiBkZWZpbmVkIChXSU5ET1dTTlQpCisvKiBEZWZpbmVkIGluIHczMi5jLiAgKi8KK2V4 dGVybiBjaGFyICp3MzJfZW1hY3Nfcm9vdF9kaXIgKHZvaWQpOworI2VuZGlmIC8qIE1TRE9TICov CiAKICNpZmRlZiBIQVZFX05BVElWRV9DT01QCiBJTkxJTkUgYm9vbApkaWZmIC0tZ2l0IGEvc3Jj L21zZG9zLmMgYi9zcmMvbXNkb3MuYwppbmRleCBiNWYwNmM5OWMzLi4wODI3Y2M5NmNkIDEwMDY0 NAotLS0gYS9zcmMvbXNkb3MuYworKysgYi9zcmMvbXNkb3MuYwpAQCAtMzM1MCw3ICszMzUwLDcg QEAgZ2V0ZGVmZGlyIChpbnQgZHJpdmUsIGNoYXIgKmRzdCkKIH0KIAogY2hhciAqCi1lbWFjc19y b290X2RpciAodm9pZCkKK2Rvc19lbWFjc19yb290X2RpciAodm9pZCkKIHsKICAgc3RhdGljIGNo YXIgcm9vdF9kaXJbNF07CiAKZGlmZiAtLWdpdCBhL3NyYy93MzIuYyBiL3NyYy93MzIuYwppbmRl eCAzZTcxZDBkMzgzLi5iY2U4MzcxMTY0IDEwMDY0NAotLS0gYS9zcmMvdzMyLmMKKysrIGIvc3Jj L3czMi5jCkBAIC0zMTQ3LDcgKzMxNDcsNyBAQCAjZGVmaW5lIFNFVF9FTlZfQlVGX1NJWkUgKDQg KiBNQVhfUEFUSCkJLyogdG8gY292ZXIgRU1BQ1NMT0FEUEFUSCAqLwogLyogQ2FsbGVkIGZyb20g ZXhwYW5kLWZpbGUtbmFtZSB3aGVuIGRlZmF1bHQtZGlyZWN0b3J5IGlzIG5vdCBhIHN0cmluZy4g ICovCiAKIGNoYXIgKgotZW1hY3Nfcm9vdF9kaXIgKHZvaWQpCit3MzJfZW1hY3Nfcm9vdF9kaXIg KHZvaWQpCiB7CiAgIHN0YXRpYyBjaGFyIHJvb3RfZGlyW01BWF9VVEY4X1BBVEhdOwogICBjb25z dCBjaGFyICpwOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --00000000000008b03c05a6dd7a95 Content-Type: application/octet-stream; name="0002-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Disposition: attachment; filename="0002-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kato20ah1 RnJvbSBmYzJiNzcwODA1ZDA2NGQzMzY5ZGRiZWUwNDY4ZmZiODViM2MzYTcyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMTow MzowMCAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMi80XSBEbyBub3QgY2FsbCBgZ2Vuc3ltJyB0b28g ZWFybHkgd2hlbiBsb2FkaW5nIGEgZHVtcCBmaWxlLgoKVGhpcyBoYXBwZW5lZCB3aGVuIHN1YnIu ZWxuIHdhcyBub3QgdGhlIGZpcnN0IG5hdGl2ZSBjb21waWxhdGlvbiB1bml0CnRvIGJlIGxvYWRl ZC4gcmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCgpIGlzIGNhbGxlZCB3aGVuIGxvYWRpbmcgYQpu YXRpdmUgY29tcGlsYXRpb24gdW5pdCBhbmQgdGhhdCBpbiB0dXJuIHVzZWQgdG8gY2FsbCBgZ2Vu c3ltJywgd2hpY2gKd2FzIG5vdCBsb2FkZWQgeWV0LiBUaGlzIGxlZCB0byBhIFNJR1NFR1YuCgoq IHNyYy9jb21wLmMgKHJlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQpOiBSZXBsYWNlIHRoZSBjYWxs IHRvIGBnZW5zeW0nCndpdGggYW4gYWQtaG9jIGNvdW50ZXIuCi0tLQogc3JjL2NvbXAuYyB8IDEw ICsrKysrKysrKy0KIDEgZmlsZSBjaGFuZ2VkLCA5IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24o LSkKCmRpZmYgLS1naXQgYS9zcmMvY29tcC5jIGIvc3JjL2NvbXAuYwppbmRleCAzMmE5ODE3M2Q1 Li45Njk4MzkzZjcwIDEwMDY0NAotLS0gYS9zcmMvY29tcC5jCisrKyBiL3NyYy9jb21wLmMKQEAg LTQxMjAsNyArNDEyMCwxNSBAQCBmaW5pc2hfZGVsYXllZF9kaXNwb3NhbF9vZl9jb21wX3VuaXRz ICh2b2lkKQogcmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCAoTGlzcF9PYmplY3QgY29tcF91KQog ewogI2lmZGVmIFdJTkRPV1NOVAotICBGcHV0aGFzaCAoQ0FMTDFJIChnZW5zeW0sIFFuaWwpLCBj b21wX3UsIGFsbF9sb2FkZWRfY29tcF91bml0c19oKTsKKyAgLyogV2UgaGF2ZSB0byBkbyB0aGlz IHNpbmNlIHdlIGNhbid0IHVzZSBgZ2Vuc3ltJy4gVGhpcyBmdW5jdGlvbiBpcworICAgICBjYWxs ZWQgZWFybHkgd2hlbiBsb2FkaW5nIGEgZHVtcCBmaWxlIGFuZCBzdWJyLmVsIG1heSBub3QgaGF2 ZQorICAgICBiZWVuIGxvYWRlZCB5ZXQuICovCisgIHN0YXRpYyBFTUFDU19VSU5UIGNvdW50Owor CisgIGlmIChjb3VudCA+PSBNT1NUX1BPU0lUSVZFX0ZJWE5VTSkKKyAgICByZXR1cm47CisKKyAg RnB1dGhhc2gobWFrZV9maXhudW0oY291bnQrKyksIGNvbXBfdSwgYWxsX2xvYWRlZF9jb21wX3Vu aXRzX2gpOwogI2VuZGlmCiB9CiAKLS0gCjIuMjUuMS53aW5kb3dzLjEKCg== --00000000000008b03c05a6dd7a95 Content-Type: application/octet-stream; name="0003-Fix-loading-of-libgccjit.dll-while-dumping-in-Window.patch" Content-Disposition: attachment; filename="0003-Fix-loading-of-libgccjit.dll-while-dumping-in-Window.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kato20al2 RnJvbSAzMTRmYzgyYWUzYTUwNTBlZDFiNmZkMDZiYjA1N2YyNmI3NDBlZTJhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMTow ODozNyAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMy80XSBGaXggbG9hZGluZyBvZiBsaWJnY2NqaXQu ZGxsIHdoaWxlIGR1bXBpbmcgaW4gV2luZG93cy4KCmxvYWR1cC5lbCBjYWxscyBgbmF0aXZlLWNv bXAtYXZhaWxhYmxlLXAnLCB0aGF0IGNhbGxzCmxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSgpIGlu IFdpbmRvd3MuIFRoYXQgZnVuY3Rpb24gdHJpZXMgdG8gbG9hZApsaWJnY2NqaXQgdXNpbmcgdGhl IG1hcHBpbmdzIGRlZmluZWQgaW4gYGR5bmFtaWMtbGlicmFyeS1hbGlzdCcuIFRoYXQKbWFwcGlu ZyBpcyBmaWxsZWQgYnkgdGVybS93MzItd2luLmVsLCBidXQgdGhhdCBmaWxlIG1heSBiZSBsb2Fk ZWQgdG9vCmxhdGUuCgoqIHNyYy9lbWFjcy5jIChzeW1zX29mX2VtYWNzKTogQWRkIGxpYmdjY2pp dCB0byB0aGUKYGR5bmFtaWMtbGlicmFyeS1hbGlzdCcgdXNlZCB3aGVuIHN0YXJ0aW5nIHRvIGR1 bXAgc28KYG5hdGl2ZS1jb21wLWF2YWlsYWJsZS1wJyBhbHdheXMgd29ya3MgaW4gV2luZG93cy4K LS0tCiBzcmMvZW1hY3MuYyB8IDggKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2VydGlv bnMoKykKCmRpZmYgLS1naXQgYS9zcmMvZW1hY3MuYyBiL3NyYy9lbWFjcy5jCmluZGV4IDM1YWU5 ZDBlNjYuLjkwMDM1YmMzYTMgMTAwNjQ0Ci0tLSBhL3NyYy9lbWFjcy5jCisrKyBiL3NyYy9lbWFj cy5jCkBAIC0zMDUzLDcgKzMwNTMsMTUgQEAgc3ltc19vZl9lbWFjcyAodm9pZCkKIAogQWxzbyBu b3RlIHRoYXQgdGhpcyBpcyBub3QgYSBnZW5lcmljIGZhY2lsaXR5IGZvciBhY2Nlc3NpbmcgZXh0 ZXJuYWwKIGxpYnJhcmllczsgb25seSB0aG9zZSBhbHJlYWR5IGtub3duIGJ5IEVtYWNzIHdpbGwg YmUgbG9hZGVkLiAgKi8pOworI2lmZGVmIFdJTkRPV1NOVAorICAvKiBXZSBtYXkgbmVlZCB0byBs b2FkIGxpYmdjY2ppdCB3aGVuIGR1bXBpbmcgYmVmb3JlIHRlcm0vdzMyLXdpbi5lbAorICAgICBk ZWZpbmVzIGBkeW5hbWljLWxpYnJhcnktYWxpc3RgLiBUaGlzIHdpbGwgZmFpbCBpZiB0aGF0IHZh cmlhYmxlCisgICAgIGlzIGVtcHR5LCBzbyBhZGQgbGliZ2Njaml0LmRsbCB0byBpdC4gKi8KKyAg VmR5bmFtaWNfbGlicmFyeV9hbGlzdCA9IGxpc3QxKGxpc3QyKFFnY2NqaXQsCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBidWlsZF9zdHJpbmcoImxpYmdjY2ppdC5kbGwi KSkpOworI2Vsc2UKICAgVmR5bmFtaWNfbGlicmFyeV9hbGlzdCA9IFFuaWw7CisjZW5kaWYKICAg RnB1dCAoaW50ZXJuX2Nfc3RyaW5nICgiZHluYW1pYy1saWJyYXJ5LWFsaXN0IiksIFFyaXNreV9s b2NhbF92YXJpYWJsZSwgUXQpOwogCiAjaWZkZWYgV0lORE9XU05UCi0tIAoyLjI1LjEud2luZG93 cy4xCgo= --00000000000008b03c05a6dd7a95 Content-Type: application/octet-stream; name="0004-Use-Windows-allocation-APIs-for-delayed_comp_unit_di.patch" Content-Disposition: attachment; filename="0004-Use-Windows-allocation-APIs-for-delayed_comp_unit_di.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kato20ao3 RnJvbSBlZTgyYmE1N2ZiNTM5NzcxOTI5NmQ4ODJmYzdiMGJmNTEzMWUxOWI4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMToy NTo1NSAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggNC80XSBVc2UgV2luZG93cyBhbGxvY2F0aW9uIEFQ SXMgZm9yCiBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0LgoKVGhhdCBsaXN0IGFuZCBh c3NvY2lhdGVkIGluZm9ybWF0aW9uIG5lZWQgdG8gYmUgYXZhaWxhYmxlIHJpZ2h0IHVudGlsCkVt YWNzIGNsb3Nlcy4gVGhpcyBpcyBub3QgcmVhbGlhYmxlIHdoZW4gdXNpbmcgeG1hbGxvYygpLgoK KiBzcmMvY29tcC5jOiBVc2UgSGVhcEZyZWUgYW5kIEhlYXBBbGxvYyBpbnN0ZWFkIG9mIHhmcmVl KCkgYW5kCnhtYWxsb2MoKSB3aGVuIGFsbG9jYXRpbmcgbm9kZXMgb2YgZGVsYXllZF9jb21wX3Vu aXRfZGlzcG9zYWxfbGlzdCBhbmQKdGhlICJjZmlsZSIgbWVtYmVyIG9mIExpc3BfTmF0aXZlX0Nv bXBfVW5pdC4KKiBzcmMvcGR1bXBlci5jIChkdW1wX2RvX2R1bXBfcmVsb2NhdGlvbik6IFVzZSBI ZWFwQWxsb2MgZm9yCmFsbG9jYXRpbmcgdGhlICJjZmlsZSIgbWVtYmVyIG9mIExpc3BfTmF0aXZl X0NvbXBfVW5pdC4KLS0tCiBzcmMvY29tcC5jICAgIHwgMTMgKysrKysrKystLS0tLQogc3JjL3Bk dW1wZXIuYyB8ICA0ICsrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgNiBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvY29tcC5jIGIvc3JjL2NvbXAuYwppbmRleCA5 Njk4MzkzZjcwLi45OTYxNjhiYmI1IDEwMDY0NAotLS0gYS9zcmMvY29tcC5jCisrKyBiL3NyYy9j b21wLmMKQEAgLTQxMDgsOCArNDEwOCw4IEBAIGZpbmlzaF9kZWxheWVkX2Rpc3Bvc2FsX29mX2Nv bXBfdW5pdHMgKHZvaWQpCiAgICAgICBMaXNwX09iamVjdCBkaXJuYW1lID0gaW50ZXJuYWxfY29u ZGl0aW9uX2Nhc2VfMSAoCiAgICAgICAgICAgRmZpbGVfbmFtZV9kaXJlY3RvcnksIGJ1aWxkX3N0 cmluZyAoaXRlbS0+ZmlsZW5hbWUpLCBRdCwgcmV0dXJuX25pbCk7CiAgICAgICBjbGVhbl9jb21w X3VuaXRfZGlyZWN0b3J5IChkaXJuYW1lKTsKLSAgICAgIHhmcmVlIChpdGVtLT5maWxlbmFtZSk7 Ci0gICAgICB4ZnJlZSAoaXRlbSk7CisgICAgICBIZWFwRnJlZSAoR2V0UHJvY2Vzc0hlYXAgKCks IDAsIGl0ZW0tPmZpbGVuYW1lKTsKKyAgICAgIEhlYXBGcmVlIChHZXRQcm9jZXNzSGVhcCAoKSwg MCwgaXRlbSk7CiAgICAgfQogfQogI2VuZGlmCkBAIC00MTUyLDEzICs0MTUyLDE1IEBAIGRpc3Bv c2VfY29tcF91bml0IChzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICpjb21wX2hhbmRsZSwg Ym9vbCBkZWxheSkKICAgICAgICAgICByZXR1cm5fbmlsKTsKICAgICAgIGlmICghTklMUCAoZGly bmFtZSkpCiAgICAgICAgIGNsZWFuX2NvbXBfdW5pdF9kaXJlY3RvcnkgKGRpcm5hbWUpOwotICAg ICAgeGZyZWUgKGNvbXBfaGFuZGxlLT5jZmlsZSk7CisgICAgICBIZWFwRnJlZSAoR2V0UHJvY2Vz c0hlYXAgKCksIDAsIGNvbXBfaGFuZGxlLT5jZmlsZSk7CiAgICAgICBjb21wX2hhbmRsZS0+Y2Zp bGUgPSBOVUxMOwogICAgIH0KICAgZWxzZQogICAgIHsKICAgICAgIHN0cnVjdCBkZWxheWVkX2Nv bXBfdW5pdF9kaXNwb3NhbCAqaGVhZDsKLSAgICAgIGhlYWQgPSB4bWFsbG9jIChzaXplb2YgKHN0 cnVjdCBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbCkpOworICAgICAgaGVhZCA9IEhlYXBBbGxv YyAoR2V0UHJvY2Vzc0hlYXAgKCksCisgICAgICAgICAgICAgICAgICAgICAgICAwLAorICAgICAg ICAgICAgICAgICAgICAgICAgc2l6ZW9mIChzdHJ1Y3QgZGVsYXllZF9jb21wX3VuaXRfZGlzcG9z YWwpKTsKICAgICAgIGhlYWQtPm5leHQgPSBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9saXN0 OwogICAgICAgaGVhZC0+ZmlsZW5hbWUgPSBjb21wX2hhbmRsZS0+Y2ZpbGU7CiAgICAgICBjb21w X2hhbmRsZS0+Y2ZpbGUgPSBOVUxMOwpAQCAtNDU1Miw3ICs0NTU0LDggQEAgREVGVU4gKCJuYXRp dmUtZWxpc3AtbG9hZCIsIEZuYXRpdmVfZWxpc3BfbG9hZCwgU25hdGl2ZV9lbGlzcF9sb2FkLCAx LCAyLCAwLAogICAgIHhzaWduYWwyIChRbmF0aXZlX2xpc3BfbG9hZF9mYWlsZWQsIGZpbGUsIGJ1 aWxkX3N0cmluZyAoZHlubGliX2Vycm9yICgpKSk7CiAgIGNvbXBfdS0+ZmlsZSA9IGZpbGU7CiAj aWZkZWYgV0lORE9XU05UCi0gIGNvbXBfdS0+Y2ZpbGUgPSB4bGlzcHN0cmR1cCAoZmlsZSk7Cisg IGNvbXBfdS0+Y2ZpbGUgPSBIZWFwQWxsb2MgKEdldFByb2Nlc3NIZWFwICgpLCAwLCAxICsgU0JZ VEVTIChmaWxlKSk7CisgIHN0cmNweSAoY29tcF91LT5jZmlsZSwgU1NEQVRBIChmaWxlKSk7CiAj ZW5kaWYKICAgY29tcF91LT5kYXRhX3ZlYyA9IFFuaWw7CiAgIGNvbXBfdS0+bGFtYmRhX2djX2d1 YXJkID0gQ0FMTE4gKEZtYWtlX2hhc2hfdGFibGUsIFFDdGVzdCwgUWVxKTsKZGlmZiAtLWdpdCBh L3NyYy9wZHVtcGVyLmMgYi9zcmMvcGR1bXBlci5jCmluZGV4IDI5ZTM1NjBlZTUuLjY4YTdhOWE1 MzYgMTAwNjQ0Ci0tLSBhL3NyYy9wZHVtcGVyLmMKKysrIGIvc3JjL3BkdW1wZXIuYwpAQCAtNTMy MSw3ICs1MzIxLDkgQEAgZHVtcF9kb19kdW1wX3JlbG9jYXRpb24gKGNvbnN0IHVpbnRwdHJfdCBk dW1wX2Jhc2UsCiAJCSAgIGluc3RhbGxhdGlvbl9zdGF0ZSA9PSBJTlNUQUxMRUQKIAkJICAgPyBY Q0FSIChjb21wX3UtPmZpbGUpIDogWENEUiAoY29tcF91LT5maWxlKSk7CiAjaWZkZWYgV0lORE9X U05UCi0JY29tcF91LT5jZmlsZSA9IHhsaXNwc3RyZHVwIChjb21wX3UtPmZpbGUpOworICAgICAg ICBjb21wX3UtPmNmaWxlID0gSGVhcEFsbG9jIChHZXRQcm9jZXNzSGVhcCAoKSwgMCwKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSArIFNCWVRFUyAoY29tcF91LT5maWxlKSk7 CisgICAgICAgIHN0cmNweSAoY29tcF91LT5jZmlsZSwgU1NEQVRBIChjb21wX3UtPmZpbGUpKTsK ICNlbmRpZgogCWNvbXBfdS0+aGFuZGxlID0gZHlubGliX29wZW4gKFNTREFUQSAoY29tcF91LT5m aWxlKSk7CiAJaWYgKCFjb21wX3UtPmhhbmRsZSkKLS0gCjIuMjUuMS53aW5kb3dzLjEKCg== --00000000000008b03c05a6dd7a95-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 10:15:37 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 14:15:37 +0000 Received: from localhost ([127.0.0.1]:58832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2Gt-0002v4-VW for submit@debbugs.gnu.org; Sat, 30 May 2020 10:15:37 -0400 Received: from mx.sdf.org ([205.166.94.20]:55807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2Gq-0002uu-RL for 41242@debbugs.gnu.org; Sat, 30 May 2020 10:15:34 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04UEFU2w004365 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 30 May 2020 14:15:30 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04UEFUPG001690; Sat, 30 May 2020 14:15:30 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Sat, 30 May 2020 14:15:30 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 13 May 2020 16:26:57 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain Hi Nico, my comments on "Reduce the number of files probed when finding a lisp file.", the full patch attached in case somebody likes to engage. > diff --git a/src/lread.c b/src/lread.c > index 46725d9b0f..aaf4ad1a37 100644 > --- a/src/lread.c > +++ b/src/lread.c > @@ -1056,33 +1056,25 @@ This uses the variables `load-suffixes' and `load-file-rep-suffixes'. */) > { > Lisp_Object exts = Vload_file_rep_suffixes; > Lisp_Object suffix = XCAR (suffixes); > - FOR_EACH_TAIL (exts) > - lst = Fcons (concat2 (suffix, XCAR (exts)), lst); > + if (false > +#ifdef HAVE_MODULES > + || strcmp (MODULES_SUFFIX, SSDATA (suffix)) == 0 > +#ifdef MODULES_SECONDARY_SUFFIX > + || strcmp (MODULES_SECONDARY_SUFFIX, SSDATA (suffix)) == 0 > +#endif > +#endif > +#ifdef HAVE_NATIVE_COMP > + || strcmp (NATIVE_ELISP_SUFFIX, SSDATA (suffix)) == 0 > +#endif > + ) We can also use NATIVE_COMP_FLAG instead of HAVE_NATIVE_COMP to limit the macrology when we are not forced to ifdef out code that involves data structures only defined with native-comp. > + lst = Fcons (suffix, lst); > + else > + FOR_EACH_TAIL (exts) > + lst = Fcons (concat2 (suffix, XCAR (exts)), lst); > } > return Fnreverse (lst); > } > > -static Lisp_Object > -effective_load_path (void) > -{ > -#ifndef HAVE_NATIVE_COMP > - return Vload_path; > -#else > - Lisp_Object lp = Vload_path; > - Lisp_Object new_lp = Qnil; > - FOR_EACH_TAIL (lp) > - { > - Lisp_Object el = XCAR (lp); > - new_lp = > - Fcons (concat2 (Ffile_name_as_directory (el), > - Vcomp_native_path_postfix), > - new_lp); > - new_lp = Fcons (el, new_lp); > - } > - return Fnreverse (new_lp); > -#endif > -} > - > /* Return true if STRING ends with SUFFIX. */ > bool > suffix_p (Lisp_Object string, const char *suffix) > @@ -1217,6 +1209,9 @@ Return t if the file exists and loads successfully. */) > #ifdef MODULES_SECONDARY_SUFFIX > || suffix_p (file, MODULES_SECONDARY_SUFFIX) > #endif > +#endif > +#ifdef HAVE_NATIVE_COMP > + || suffix_p (file, NATIVE_ELISP_SUFFIX) > #endif > ) Same as previous comment. > must_suffix = Qnil; > @@ -1236,8 +1231,8 @@ Return t if the file exists and loads successfully. */) > } > > fd = > - openp (effective_load_path (), file, suffixes, &found, Qnil, > - load_prefer_newer); > + openp (Vload_path, file, true, suffixes, &found, Qnil, > + load_prefer_newer); > } > > if (fd == -1) > @@ -1600,7 +1595,7 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) > (Lisp_Object filename, Lisp_Object path, Lisp_Object suffixes, Lisp_Object predicate) > { > Lisp_Object file; > - int fd = openp (path, filename, suffixes, &file, predicate, false); > + int fd = openp (path, filename, Qnil, suffixes, &file, predicate, false); ^^^ false? > if (NILP (predicate) && fd >= 0) > emacs_close (fd); > return file; > @@ -1611,6 +1606,9 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) > On success, return a file descriptor (or 1 or -2 as described below). > On failure, return -1 and set errno. > > + If ADD_ELN_DIR is nonzero, use the `comp-native-path-postfix' > + variable to change the searched path if the suffix is .eln. > + Is there a specific reason to add a parameter to exclude/includes elns? I'd say we want to have an homogeneous behavior across all call sites no? > SUFFIXES is a list of strings containing possible suffixes. > The empty suffix is automatically added if the list is empty. > > @@ -1633,8 +1631,9 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) > or if a non-nil and non-t PREDICATE is specified. */ > > int > -openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > - Lisp_Object *storeptr, Lisp_Object predicate, bool newer) > +openp (Lisp_Object path, Lisp_Object str, bool add_eln_dir, > + Lisp_Object suffixes, Lisp_Object *storeptr, Lisp_Object predicate, > + bool newer) > { > ptrdiff_t fn_size = 100; > char buf[100]; > @@ -1643,7 +1642,7 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > ptrdiff_t want_length; > Lisp_Object filename; > Lisp_Object string, tail, encoded_fn, save_string; > - ptrdiff_t max_suffix_len = 0; > + ptrdiff_t max_extra_len = 0; > int last_errno = ENOENT; > int save_fd = -1; > USE_SAFE_ALLOCA; > @@ -1658,8 +1657,15 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > FOR_EACH_TAIL_SAFE (tail) > { > CHECK_STRING_CAR (tail); > - max_suffix_len = max (max_suffix_len, > - SBYTES (XCAR (tail))); > + char * suf = SSDATA (XCAR (tail)); ^^ no space > + ptrdiff_t len = SBYTES (XCAR (tail)); > + if (add_eln_dir && strcmp (NATIVE_ELISP_SUFFIX, suf) == 0) > + { > + CHECK_STRING (Vcomp_native_path_postfix); > + len += 2; > + len += SBYTES (Vcomp_native_path_postfix); > + } > + max_extra_len = max (max_extra_len, len); > } > > string = filename = encoded_fn = save_string = Qnil; > @@ -1677,7 +1683,7 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > executable. */ > FOR_EACH_TAIL_SAFE (path) > { > - ptrdiff_t baselen, prefixlen; > + ptrdiff_t dirnamelen, prefixlen, basenamewext_len; > > if (EQ (path, just_use_str)) > filename = str; > @@ -1694,22 +1700,27 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > continue; > } > > + > /* Calculate maximum length of any filename made from > this path element/specified file name and any possible suffix. */ > - want_length = max_suffix_len + SBYTES (filename); > + want_length = max_extra_len + SBYTES (filename); > if (fn_size <= want_length) > { > fn_size = 100 + want_length; > fn = SAFE_ALLOCA (fn_size); > } > > + Lisp_Object dirnamewslash = Ffile_name_directory (filename); > + Lisp_Object basenamewext = Ffile_name_nondirectory (filename); > + > /* Copy FILENAME's data to FN but remove starting /: if any. */ > - prefixlen = ((SCHARS (filename) > 2 > - && SREF (filename, 0) == '/' > - && SREF (filename, 1) == ':') > + prefixlen = ((SCHARS (dirnamewslash) > 2 > + && SREF (dirnamewslash, 0) == '/' > + && SREF (dirnamewslash, 1) == ':') > ? 2 : 0); > - baselen = SBYTES (filename) - prefixlen; > - memcpy (fn, SDATA (filename) + prefixlen, baselen); > + dirnamelen = SBYTES (dirnamewslash) - prefixlen; > + basenamewext_len = SBYTES (basenamewext); > + memcpy (fn, SDATA (dirnamewslash) + prefixlen, dirnamelen); > > /* Loop over suffixes. */ > AUTO_LIST1 (empty_string_only, empty_unibyte_string); > @@ -1719,10 +1730,24 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, > Lisp_Object suffix = XCAR (tail); > ptrdiff_t fnlen, lsuffix = SBYTES (suffix); > Lisp_Object handler; > + bool add_native_comp_dir = add_eln_dir > + && (strcmp (SSDATA (suffix), NATIVE_ELISP_SUFFIX) == 0); I think this should be optimized for non native comp builds with a NATIVE_COMP_FLAG && in front. > + ptrdiff_t lmiddledir = add_native_comp_dir > + ? SBYTES (Vcomp_native_path_postfix) + 1 : 0; > + > + if (add_native_comp_dir) > + { > + memcpy (fn + dirnamelen, SDATA (Vcomp_native_path_postfix), > + lmiddledir - 1); Vcomp_native_path_postfix is only defined with HAVE_NATIVE_COMP so I guess this breaks the stock build and my previous suggestion is not applicable. > + fn[dirnamelen+(lmiddledir-1)] = '/'; Spaces around operators + -. I could not compile this patch because non all the calls to openp has been updated for the new parameter (my question on adding this stands). In general please recall to check the stock build when working on infrastructure integration, it's quite easy to break. Generally speaking I think the behavior we want to have is that when a .eln file is specified this is loaded without re-adding Vcomp_native_path_postfix. I could not test it but I suspect this is not handled. Thanks this is good to have in when tuned. Andrea -- akrl@sdf.org --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Reduce-the-number-of-files-probed-when-finding-a-lis.patch >From d6b6ac651c62e6a5cd9701d94419cfd53e95976e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Nicol=C3=A1s=20B=C3=A9rtolo?= Date: Mon, 25 May 2020 18:05:23 -0300 Subject: [PATCH] Reduce the number of files probed when finding a lisp file. * src/lread.c (get-load-suffixes): Do not add any suffix to files that need to be loaded by the dynamic linker. (effective_load_path): Remove function. (load): Don't add any suffix if file ends in a suffix already. (openp): Add a parameter `add_eln_dir` that should be used when we desire the dir elt/eln-hash/ to be searched for each path in `path`. * src/lisp.h: Add new parameter to openp. * src/callproc.c: Add the new parameter to calls to openp(). * src/charset.c: Add the new parameter to calls to openp(). * src/emacs.c: Add the new parameter to calls to openp(). * src/image.c: Add the new parameter to calls to openp(). * src/process.c: Add the new parameter to calls to openp(). * src/w32.c: Add the new parameter to calls to openp(). * src/w32proc.c: Add the new parameter to calls to openp(). --- src/callproc.c | 2 +- src/charset.c | 2 +- src/emacs.c | 3 +- src/image.c | 4 +- src/lisp.h | 2 +- src/lread.c | 107 ++++++++++++++++++++++++++++++------------------- src/process.c | 2 +- src/w32.c | 3 +- src/w32proc.c | 3 +- 9 files changed, 78 insertions(+), 50 deletions(-) diff --git a/src/callproc.c b/src/callproc.c index 65c858393a..421e42de11 100644 --- a/src/callproc.c +++ b/src/callproc.c @@ -436,7 +436,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, { int ok; - ok = openp (Vexec_path, args[0], Vexec_suffixes, &path, + ok = openp (Vexec_path, args[0], false, Vexec_suffixes, &path, make_fixnum (X_OK), false); if (ok < 0) report_file_error ("Searching for program", args[0]); diff --git a/src/charset.c b/src/charset.c index 8635aad3ed..da3ace743f 100644 --- a/src/charset.c +++ b/src/charset.c @@ -486,7 +486,7 @@ load_charset_map_from_file (struct charset *charset, Lisp_Object mapfile, ptrdiff_t count = SPECPDL_INDEX (); record_unwind_protect_nothing (); specbind (Qfile_name_handler_alist, Qnil); - fd = openp (Vcharset_map_path, mapfile, suffixes, NULL, Qnil, false); + fd = openp (Vcharset_map_path, mapfile, false, suffixes, NULL, Qnil, false); fp = fd < 0 ? 0 : fdopen (fd, "r"); if (!fp) { diff --git a/src/emacs.c b/src/emacs.c index cd4f7a0b28..35ae9d0e66 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -454,7 +454,8 @@ set_invocation_vars (char *argv0, char const *original_pwd) { Lisp_Object found; int yes = openp (Vexec_path, Vinvocation_name, - Vexec_suffixes, &found, make_fixnum (X_OK), false); + false, Vexec_suffixes, &found, make_fixnum (X_OK), + false); if (yes == 1) { /* Add /: to the front of the name diff --git a/src/image.c b/src/image.c index c8a192aaaf..80ef801913 100644 --- a/src/image.c +++ b/src/image.c @@ -508,7 +508,7 @@ image_create_bitmap_from_file (struct frame *f, Lisp_Object file) } /* Search bitmap-file-path for the file, if appropriate. */ - if (openp (Vx_bitmap_file_path, file, Qnil, &found, + if (openp (Vx_bitmap_file_path, file, false, Qnil, &found, make_fixnum (R_OK), false) < 0) return -1; @@ -2983,7 +2983,7 @@ image_find_image_fd (Lisp_Object file, int *pfd) Vx_bitmap_file_path); /* Try to find FILE in data-directory/images, then x-bitmap-file-path. */ - fd = openp (search_path, file, Qnil, &file_found, + fd = openp (search_path, file, false, Qnil, &file_found, pfd ? Qt : make_fixnum (R_OK), false); if (fd >= 0 || fd == -2) { diff --git a/src/lisp.h b/src/lisp.h index 52242791aa..5f921d58dc 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4094,7 +4094,7 @@ LOADHIST_ATTACH (Lisp_Object x) extern bool suffix_p (Lisp_Object, const char *); extern Lisp_Object save_match_data_load (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object); -extern int openp (Lisp_Object, Lisp_Object, Lisp_Object, +extern int openp (Lisp_Object, Lisp_Object, bool, Lisp_Object, Lisp_Object *, Lisp_Object, bool); enum { S2N_IGNORE_TRAILING = 1 }; extern Lisp_Object string_to_number (char const *, int, ptrdiff_t *); diff --git a/src/lread.c b/src/lread.c index 46725d9b0f..aaf4ad1a37 100644 --- a/src/lread.c +++ b/src/lread.c @@ -1056,33 +1056,25 @@ This uses the variables `load-suffixes' and `load-file-rep-suffixes'. */) { Lisp_Object exts = Vload_file_rep_suffixes; Lisp_Object suffix = XCAR (suffixes); - FOR_EACH_TAIL (exts) - lst = Fcons (concat2 (suffix, XCAR (exts)), lst); + if (false +#ifdef HAVE_MODULES + || strcmp (MODULES_SUFFIX, SSDATA (suffix)) == 0 +#ifdef MODULES_SECONDARY_SUFFIX + || strcmp (MODULES_SECONDARY_SUFFIX, SSDATA (suffix)) == 0 +#endif +#endif +#ifdef HAVE_NATIVE_COMP + || strcmp (NATIVE_ELISP_SUFFIX, SSDATA (suffix)) == 0 +#endif + ) + lst = Fcons (suffix, lst); + else + FOR_EACH_TAIL (exts) + lst = Fcons (concat2 (suffix, XCAR (exts)), lst); } return Fnreverse (lst); } -static Lisp_Object -effective_load_path (void) -{ -#ifndef HAVE_NATIVE_COMP - return Vload_path; -#else - Lisp_Object lp = Vload_path; - Lisp_Object new_lp = Qnil; - FOR_EACH_TAIL (lp) - { - Lisp_Object el = XCAR (lp); - new_lp = - Fcons (concat2 (Ffile_name_as_directory (el), - Vcomp_native_path_postfix), - new_lp); - new_lp = Fcons (el, new_lp); - } - return Fnreverse (new_lp); -#endif -} - /* Return true if STRING ends with SUFFIX. */ bool suffix_p (Lisp_Object string, const char *suffix) @@ -1217,6 +1209,9 @@ Return t if the file exists and loads successfully. */) #ifdef MODULES_SECONDARY_SUFFIX || suffix_p (file, MODULES_SECONDARY_SUFFIX) #endif +#endif +#ifdef HAVE_NATIVE_COMP + || suffix_p (file, NATIVE_ELISP_SUFFIX) #endif ) must_suffix = Qnil; @@ -1236,8 +1231,8 @@ Return t if the file exists and loads successfully. */) } fd = - openp (effective_load_path (), file, suffixes, &found, Qnil, - load_prefer_newer); + openp (Vload_path, file, true, suffixes, &found, Qnil, + load_prefer_newer); } if (fd == -1) @@ -1600,7 +1595,7 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) (Lisp_Object filename, Lisp_Object path, Lisp_Object suffixes, Lisp_Object predicate) { Lisp_Object file; - int fd = openp (path, filename, suffixes, &file, predicate, false); + int fd = openp (path, filename, Qnil, suffixes, &file, predicate, false); if (NILP (predicate) && fd >= 0) emacs_close (fd); return file; @@ -1611,6 +1606,9 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) On success, return a file descriptor (or 1 or -2 as described below). On failure, return -1 and set errno. + If ADD_ELN_DIR is nonzero, use the `comp-native-path-postfix' + variable to change the searched path if the suffix is .eln. + SUFFIXES is a list of strings containing possible suffixes. The empty suffix is automatically added if the list is empty. @@ -1633,8 +1631,9 @@ directories, make sure the PREDICATE function returns `dir-ok' for them. */) or if a non-nil and non-t PREDICATE is specified. */ int -openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, - Lisp_Object *storeptr, Lisp_Object predicate, bool newer) +openp (Lisp_Object path, Lisp_Object str, bool add_eln_dir, + Lisp_Object suffixes, Lisp_Object *storeptr, Lisp_Object predicate, + bool newer) { ptrdiff_t fn_size = 100; char buf[100]; @@ -1643,7 +1642,7 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, ptrdiff_t want_length; Lisp_Object filename; Lisp_Object string, tail, encoded_fn, save_string; - ptrdiff_t max_suffix_len = 0; + ptrdiff_t max_extra_len = 0; int last_errno = ENOENT; int save_fd = -1; USE_SAFE_ALLOCA; @@ -1658,8 +1657,15 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, FOR_EACH_TAIL_SAFE (tail) { CHECK_STRING_CAR (tail); - max_suffix_len = max (max_suffix_len, - SBYTES (XCAR (tail))); + char * suf = SSDATA (XCAR (tail)); + ptrdiff_t len = SBYTES (XCAR (tail)); + if (add_eln_dir && strcmp (NATIVE_ELISP_SUFFIX, suf) == 0) + { + CHECK_STRING (Vcomp_native_path_postfix); + len += 2; + len += SBYTES (Vcomp_native_path_postfix); + } + max_extra_len = max (max_extra_len, len); } string = filename = encoded_fn = save_string = Qnil; @@ -1677,7 +1683,7 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, executable. */ FOR_EACH_TAIL_SAFE (path) { - ptrdiff_t baselen, prefixlen; + ptrdiff_t dirnamelen, prefixlen, basenamewext_len; if (EQ (path, just_use_str)) filename = str; @@ -1694,22 +1700,27 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, continue; } + /* Calculate maximum length of any filename made from this path element/specified file name and any possible suffix. */ - want_length = max_suffix_len + SBYTES (filename); + want_length = max_extra_len + SBYTES (filename); if (fn_size <= want_length) { fn_size = 100 + want_length; fn = SAFE_ALLOCA (fn_size); } + Lisp_Object dirnamewslash = Ffile_name_directory (filename); + Lisp_Object basenamewext = Ffile_name_nondirectory (filename); + /* Copy FILENAME's data to FN but remove starting /: if any. */ - prefixlen = ((SCHARS (filename) > 2 - && SREF (filename, 0) == '/' - && SREF (filename, 1) == ':') + prefixlen = ((SCHARS (dirnamewslash) > 2 + && SREF (dirnamewslash, 0) == '/' + && SREF (dirnamewslash, 1) == ':') ? 2 : 0); - baselen = SBYTES (filename) - prefixlen; - memcpy (fn, SDATA (filename) + prefixlen, baselen); + dirnamelen = SBYTES (dirnamewslash) - prefixlen; + basenamewext_len = SBYTES (basenamewext); + memcpy (fn, SDATA (dirnamewslash) + prefixlen, dirnamelen); /* Loop over suffixes. */ AUTO_LIST1 (empty_string_only, empty_unibyte_string); @@ -1719,10 +1730,24 @@ openp (Lisp_Object path, Lisp_Object str, Lisp_Object suffixes, Lisp_Object suffix = XCAR (tail); ptrdiff_t fnlen, lsuffix = SBYTES (suffix); Lisp_Object handler; + bool add_native_comp_dir = add_eln_dir + && (strcmp (SSDATA (suffix), NATIVE_ELISP_SUFFIX) == 0); + ptrdiff_t lmiddledir = add_native_comp_dir + ? SBYTES (Vcomp_native_path_postfix) + 1 : 0; + + if (add_native_comp_dir) + { + memcpy (fn + dirnamelen, SDATA (Vcomp_native_path_postfix), + lmiddledir - 1); + fn[dirnamelen+(lmiddledir-1)] = '/'; + } - /* Make complete filename by appending SUFFIX. */ - memcpy (fn + baselen, SDATA (suffix), lsuffix + 1); - fnlen = baselen + lsuffix; + memcpy (fn + dirnamelen + lmiddledir, SDATA (basenamewext), + basenamewext_len); + /* Make complete filename by appending SUFFIX. */ + memcpy (fn + dirnamelen + lmiddledir + basenamewext_len, + SDATA (suffix), lsuffix + 1); + fnlen = dirnamelen + lmiddledir + basenamewext_len + lsuffix; /* Check that the file exists and is not a directory. */ /* We used to only check for handlers on non-absolute file names: diff --git a/src/process.c b/src/process.c index 6e5bcf307a..e092fa0a0c 100644 --- a/src/process.c +++ b/src/process.c @@ -1903,7 +1903,7 @@ usage: (make-process &rest ARGS) */) && IS_DEVICE_SEP (SREF (program, 1)))) { tem = Qnil; - openp (Vexec_path, program, Vexec_suffixes, &tem, + openp (Vexec_path, program, false, Vexec_suffixes, &tem, make_fixnum (X_OK), false); if (NILP (tem)) report_file_error ("Searching for program", program); diff --git a/src/w32.c b/src/w32.c index 38bbc49656..3e71d0d383 100644 --- a/src/w32.c +++ b/src/w32.c @@ -10187,7 +10187,8 @@ check_windows_init_file (void) need to ENCODE_FILE here, but we do need to convert the file names from UTF-8 to ANSI. */ init_file = build_string ("term/w32-win"); - fd = openp (Vload_path, init_file, Fget_load_suffixes (), NULL, Qnil, 0); + fd = openp (Vload_path, init_file, true, Fget_load_suffixes (), NULL, + Qnil, 0); if (fd < 0) { Lisp_Object load_path_print = Fprin1_to_string (Vload_path, Qnil); diff --git a/src/w32proc.c b/src/w32proc.c index 16e32e4c58..4aa4c9fa0a 100644 --- a/src/w32proc.c +++ b/src/w32proc.c @@ -1918,7 +1918,8 @@ sys_spawnve (int mode, char *cmdname, char **argv, char **envp) { program = build_string (cmdname); full = Qnil; - openp (Vexec_path, program, Vexec_suffixes, &full, make_fixnum (X_OK), 0); + openp (Vexec_path, program, false, Vexec_suffixes, &full, + make_fixnum (X_OK), 0); if (NILP (full)) { errno = EINVAL; -- 2.20.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 10:17:52 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 14:17:52 +0000 Received: from localhost ([127.0.0.1]:58836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2J6-0002yo-DY for submit@debbugs.gnu.org; Sat, 30 May 2020 10:17:52 -0400 Received: from mx.sdf.org ([205.166.94.20]:55506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2J4-0002yg-HE for 41242@debbugs.gnu.org; Sat, 30 May 2020 10:17:50 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04UEHneP004683 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 30 May 2020 14:17:50 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04UEHn54002824; Sat, 30 May 2020 14:17:49 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Sat, 30 May 2020 14:17:49 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 30 May 2020 10:06:34 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> I've pushed 15c121ee0b "* Avoid calling Ffile_exists_p too early" >> implementing the discussed idea. > >> Should do the job in Windows too, please give it a try. > > It works well, thank you. Great > Last night I implemented a very similar patch, but I didn't send it > because it was too late. You beat me to it. > > Nico Apologies, feel free to just drop a message to signal you are willing to or already working on something so I don't overlap. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 10:51:14 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 14:51:14 +0000 Received: from localhost ([127.0.0.1]:58889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2pN-0003q5-SS for submit@debbugs.gnu.org; Sat, 30 May 2020 10:51:14 -0400 Received: from mx.sdf.org ([205.166.94.20]:52687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf2pM-0003px-83 for 41242@debbugs.gnu.org; Sat, 30 May 2020 10:51:13 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04UEpAuc004172 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 30 May 2020 14:51:10 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04UEpAx5022144; Sat, 30 May 2020 14:51:10 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Sat, 30 May 2020 14:51:10 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 30 May 2020 10:23:55 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > I have found a few bugs in Windows. > Patches attached (they are in my repo too). > > - It is still a good idea to avoid the call to getenv("emacs_dir"), if on= ly for > performance reasons. I guess this should then go into master right? Probably also others likes to review it, in case should not be discussed in this thread. > - We can't use "gensym" for register_native_comp_unit() because the dynam= ic > library may not have been loaded yet when loading a dump file. The code LGTM, I just think instead of make_fixum you could use make_int to have some more room (not sure how much is realistic this scenario but comes for free). > - Commit `f5dceed09a8234548d5b3acb76d443569533cab9` "* lisp/loadup.el: Us= e new > 'native-comp-available-p'." causes load_gccjit_if_necessary() to be cal= led in > temacs. This didn't work because because term/w32-win.el had not been l= oaded > yet. In particular, we need `dynamic-library-alist` to be defined to kn= ow the > name of the libgccjit DLL. I have defined this in syms_of_emacs(). This > definition should be active only while dumping. I'll look into. > - This last bug is kinda confusing. I'm not sure about my diagnosis. The = list > `delayed_comp_unit_disposal_list` has nodes allocated with xmalloc(). I= t seems > that these blocks allocated with xmalloc() get GC'd or they get corrupt= ed > somehow and thus they don't survive until Emacs is about to close, whic= h is > when we need the list. I solved it by allocating the data and nodes with > HeapAlloc(). I think this issue deserves to be precisely understood. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 12:26:10 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 16:26:10 +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 1jf4JG-00067F-Cu for submit@debbugs.gnu.org; Sat, 30 May 2020 12:26:10 -0400 Received: from mail-oo1-f52.google.com ([209.85.161.52]:42821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf4JE-000672-Bf for 41242@debbugs.gnu.org; Sat, 30 May 2020 12:26:09 -0400 Received: by mail-oo1-f52.google.com with SMTP id h7so547816ooc.9 for <41242@debbugs.gnu.org>; Sat, 30 May 2020 09:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bg/JmTgYyCWbXRlSDTvsKvH09ROuDm8DvlOvosPFVZ4=; b=gl0MKBtapVnekIP40SNPyEhxGetpZFrLJIsTxjnqdbuFqewTs9aTKZQQS7vqmM++ok IgvvIeH2rViSURnU6gsT9C4486IhgwE09LvepAn6sMsegrqNaQ/dEZz8n/FIelDj16ps Vl9+P/QZRdRV6qmFPX2/OfB9toCpeRkQxMUpGEXZ3e3RTJLNSrAO+M4M/j2xhYWfMU/V kjMbnKvGH2AgrNmY+vjZY5Sfufx3iMYZkswMZNTFjZpmlPUoft3dXGkinfnvGws7Qp+n 4rStRLsrG0vZu/WXhwjgaDEpTjv2T3WeIpl7IzkyD5KYUK1JpP8ZxZkdOPdfH/dOxgFR 7Q4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bg/JmTgYyCWbXRlSDTvsKvH09ROuDm8DvlOvosPFVZ4=; b=bFcfmk0b4JwcNqKMJzV+DuudkB+AhPRT5EKC9JWUNc4IIO64/jWkWkii4PUwMjdV07 HCWKyS33s0355BVNnqZMKH+b6rMLeFJpDPEmCk2BM8HL1lrdfuU9oraBDRksI8iqcBe3 ONNo6NMGMlmivy9/OXjeNAqlxs+Col8mKoZhYsF1eRx4SYGnJCOhcf0A1RQtn7FfFehV YCqv5MW0DJMxZLRizcG1EIcEmnT2os/62NBgiP/S6t9SbbHeIY7cvuHnDorS5JVs9HSQ lso4/6v1OsqX9C1009ebaZ8F+15PE0FiJRjp4hogskxSKe3qHEdk1UFcDdZDYdtOML5S cWEA== X-Gm-Message-State: AOAM530MwRZIHc9bRpwhBYHw+7ANCMb/sY7LyORSWpeqd0ExYh2qKaKG iw1ycImSTvZLoBrGjWxo6UFM864KHVU09CBPwPmoDwtkZr8= X-Google-Smtp-Source: ABdhPJxeIl71RoEwN8PZCM1qQd3sX+iiGFf0uKSgs4+xR/DWKw2ljoVcDlWPqqWQUNidXpsD1yR1FMUMRCtYaotHmtU= X-Received: by 2002:a4a:bf14:: with SMTP id r20mr11174295oop.18.1590855962270; Sat, 30 May 2020 09:26:02 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 30 May 2020 13:25:48 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: multipart/mixed; boundary="0000000000008566d605a6e0047b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --0000000000008566d605a6e0047b Content-Type: text/plain; charset="UTF-8" > I guess this should then go into master right? Probably also others > likes to review it, in case should not be discussed in this thread. Ok, later I will open a bug report about it. > - We can't use "gensym" for register_native_comp_unit() because the dynamic > library may not have been loaded yet when loading a dump file. > The code LGTM, I just think instead of make_fixum you could use make_int > to have some more room (not sure how much is realistic this scenario but > comes for free). See new attached patch. > I'll look into. Thanks. > I think this issue deserves to be precisely understood. I was not even close. The code crashes when iterating over the `all_loaded_comp_units_h` weak hash table. We get a SIGSEGV when iterating over a native compilation unit that has already been swept by the GC. For some reason the hash table does not get updated. Maybe the code I used to iterate over the hash table is not ok for weak hash tables? ============= struct Lisp_Hash_Table *h = XHASH_TABLE (all_loaded_comp_units_h); for (ptrdiff_t i = 0; i < HASH_TABLE_SIZE (h); ++i) { Lisp_Object k = HASH_KEY (h, i); if (!EQ (k, Qunbound)) { Lisp_Object val = HASH_VALUE (h, i); struct Lisp_Native_Comp_Unit *cu = XNATIVE_COMP_UNIT (val); dispose_comp_unit (cu, false); } } ============= Thanks, Nico. --0000000000008566d605a6e0047b Content-Type: application/octet-stream; name="0001-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Disposition: attachment; filename="0001-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_katujl8g0 RnJvbSA2MWY5NDNiZWU3ODZmNzlhNzE2NGQyMmEyZTliNGViMjI0ZmNiNTk2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMTow MzowMCAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIERvIG5vdCBjYWxsIGBnZW5zeW0nIHRvbyBlYXJs eSB3aGVuIGxvYWRpbmcgYSBkdW1wIGZpbGUuCgpUaGlzIGhhcHBlbmVkIHdoZW4gc3Vici5lbG4g d2FzIG5vdCB0aGUgZmlyc3QgbmF0aXZlIGNvbXBpbGF0aW9uIHVuaXQKdG8gYmUgbG9hZGVkLiBy ZWdpc3Rlcl9uYXRpdmVfY29tcF91bml0KCkgaXMgY2FsbGVkIHdoZW4gbG9hZGluZyBhCm5hdGl2 ZSBjb21waWxhdGlvbiB1bml0IGFuZCB0aGF0IGluIHR1cm4gdXNlZCB0byBjYWxsIGBnZW5zeW0n LCB3aGljaAp3YXMgbm90IGxvYWRlZCB5ZXQuIFRoaXMgbGVkIHRvIGEgU0lHU0VHVi4KCiogc3Jj L2NvbXAuYyAocmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCk6IFJlcGxhY2UgdGhlIGNhbGwgdG8g YGdlbnN5bScKd2l0aCBhbiBhZC1ob2MgY291bnRlci4KLS0tCiBzcmMvY29tcC5jIHwgNyArKysr KystCiAxIGZpbGUgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZm IC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9jb21wLmMKaW5kZXggMzJhOTgxNzNkNS4uMzEwYWQ3 NmZiZSAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9zcmMvY29tcC5jCkBAIC00MTIwLDcg KzQxMjAsMTIgQEAgZmluaXNoX2RlbGF5ZWRfZGlzcG9zYWxfb2ZfY29tcF91bml0cyAodm9pZCkK IHJlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQgKExpc3BfT2JqZWN0IGNvbXBfdSkKIHsKICNpZmRl ZiBXSU5ET1dTTlQKLSAgRnB1dGhhc2ggKENBTEwxSSAoZ2Vuc3ltLCBRbmlsKSwgY29tcF91LCBh bGxfbG9hZGVkX2NvbXBfdW5pdHNfaCk7CisgIC8qIFdlIGhhdmUgdG8gZG8gdGhpcyBzaW5jZSB3 ZSBjYW4ndCB1c2UgYGdlbnN5bScuIFRoaXMgZnVuY3Rpb24gaXMKKyAgICAgY2FsbGVkIGVhcmx5 IHdoZW4gbG9hZGluZyBhIGR1bXAgZmlsZSBhbmQgc3Vici5lbCBtYXkgbm90IGhhdmUKKyAgICAg YmVlbiBsb2FkZWQgeWV0LiAqLworICBzdGF0aWMgaW50bWF4X3QgY291bnQ7CisKKyAgRnB1dGhh c2gobWFrZV9pbnQoY291bnQrKyksIGNvbXBfdSwgYWxsX2xvYWRlZF9jb21wX3VuaXRzX2gpOwog I2VuZGlmCiB9CiAKLS0gCjIuMjUuMS53aW5kb3dzLjEKCg== --0000000000008566d605a6e0047b-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 12:29:37 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 16:29:37 +0000 Received: from localhost ([127.0.0.1]:58960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf4Ma-0006Bq-SX for submit@debbugs.gnu.org; Sat, 30 May 2020 12:29:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf4MY-0006Bc-6b for 41242@debbugs.gnu.org; Sat, 30 May 2020 12:29:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37776) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jf4MS-0005l6-Pi; Sat, 30 May 2020 12:29:28 -0400 Received: from [176.228.60.248] (port=3035 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jf4MR-0004gp-SH; Sat, 30 May 2020 12:29:28 -0400 Date: Sat, 30 May 2020 19:29:20 +0300 Message-Id: <83wo4tl733.fsf@gnu.org> From: Eli Zaretskii To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 30 May 2020 10:23:55 -0300) Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org, akrl@sdf.org 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 (---) > From: Nicolas Bértolo > Date: Sat, 30 May 2020 10:23:55 -0300 > Cc: 41242@debbugs.gnu.org > > - Commit `f5dceed09a8234548d5b3acb76d443569533cab9` "* lisp/loadup.el: Use new > 'native-comp-available-p'." causes load_gccjit_if_necessary() to be called in > temacs. This didn't work because because term/w32-win.el had not been loaded > yet. In particular, we need `dynamic-library-alist` to be defined to know the > name of the libgccjit DLL. I have defined this in syms_of_emacs(). This > definition should be active only while dumping. If this is only for dumping, then please make sure it has the proper condition to be executed only at dump time. > - This last bug is kinda confusing. I'm not sure about my diagnosis. The list > `delayed_comp_unit_disposal_list` has nodes allocated with xmalloc(). It seems > that these blocks allocated with xmalloc() get GC'd or they get corrupted > somehow and thus they don't survive until Emacs is about to close, which is > when we need the list. I solved it by allocating the data and nodes with > HeapAlloc(). I don't understand: the malloc implementation in the Windows build calls HeapAlloc, so I see no reason why the latter should work while the former doesn't. There's some other factor at work here. In any case, it's a definite no-no to call Windows specific APIs in a general-purpose source file, so this patch as is cannot be acceptable. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 14:51:14 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 18:51:14 +0000 Received: from localhost ([127.0.0.1]:59221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf6Ze-0003VJ-3o for submit@debbugs.gnu.org; Sat, 30 May 2020 14:51:14 -0400 Received: from mx.sdf.org ([205.166.94.20]:65093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf6Zc-0003VB-E9 for 41242@debbugs.gnu.org; Sat, 30 May 2020 14:51:13 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04UIpB7A029364 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 30 May 2020 18:51:11 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04UIpBb5027153; Sat, 30 May 2020 18:51:11 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Sat, 30 May 2020 18:51:10 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 30 May 2020 13:25:48 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > --- > src/comp.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/comp.c b/src/comp.c > index 32a98173d5..310ad76fbe 100644 > --- a/src/comp.c > +++ b/src/comp.c > @@ -4120,7 +4120,12 @@ finish_delayed_disposal_of_comp_units (void) > register_native_comp_unit (Lisp_Object comp_u) > { > #ifdef WINDOWSNT > - Fputhash (CALL1I (gensym, Qnil), comp_u, all_loaded_comp_units_h); > + /* We have to do this since we can't use `gensym'. This function is > + called early when loading a dump file and subr.el may not have > + been loaded yet. */ > + static intmax_t count; > + > + Fputhash(make_int(count++), comp_u, all_loaded_comp_units_h); > #endif > } Again as suggested, *please* run 'check_GNU_style.sh' on your patches if you are not used to GNU code style to fix it. Presenting a patch correctly formatted, well tested and fully understood is a sign of respect for reviewers and the time they are going to invest in the review process. We are all volunteers and we all have to cope with time constraints. Investing time in reviews means subtracting it to other activities including working on other patches and features. We aim for code quality rather then quantity or other metrics. The followings are to be considered as basic features we want for all patches (not just this) to be applied to this branch: - Compiles and bootstrap --with-nativecomp --without-nativecomp - Formatting is correct Obviously we can always make mistakes that is totally okay, but does not have to be a routine that is expected to be fixed by reviewers. Please apply these suggestions to all patches that are submitted or pending for review to speed-up the process so we can leave the discussion for interesting topics. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 16:15:24 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 20:15:24 +0000 Received: from localhost ([127.0.0.1]:59257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf7t6-0007bh-3G for submit@debbugs.gnu.org; Sat, 30 May 2020 16:15:24 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:37524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf7t4-0007bS-TZ for 41242@debbugs.gnu.org; Sat, 30 May 2020 16:15:23 -0400 Received: by mail-oi1-f169.google.com with SMTP id m67so5734512oif.4 for <41242@debbugs.gnu.org>; Sat, 30 May 2020 13:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Jha/KupkG2WCLDKSoyWZTNjaIQMttUqAlZK8fcETaA=; b=GmwIRsH9cT5KxM4loQ8Sz2nScNY8IjCVD1gbbzNAT5Td684QkQu8GgDgzHYELnsPZK WgD2yJ9F1m2oubJCPyaI1GymTUzu43EfJA79/GAn6GPorZpcKe/gcvInNHbBzIFdMDqO AS2+XaeMbZ/nG61ECDztW6ZlOvcSdQxTKmDtM6CmBLQFEDlpNqnES0VeurYgJ+WOVCKQ EGREHq3GjIzMb1OH/UvRMR9s538+yfxSVKUGYuS4fBVeSYlou9xyYEAYaiE5dkyvc0ra F4wsr/ndTwNNuCQ4qFiZsEpY8FZpeFrrgZ6Zrbi6PaAmAzcw6lyECINWm0gsk3gER62X vvSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Jha/KupkG2WCLDKSoyWZTNjaIQMttUqAlZK8fcETaA=; b=GISPLL1Hvjz/ZrWxy7280GRtivEpoVfBdadw9IBvCFHoZcbpWCVnNvdW5Gxf4ODiex mKgcmpUKRCL77Vn9/mWuaVaOC4RN52ceFyMoPbGYNNB6eT+cEMPcPRI4RHD3A9Anr1PS 9aDCVM+35uwGlkgZ+Mc5sz/TrQf7Qje/3p12knagpmhU7/Uh7dr1BfLoEjgdim7I+l2z 25a2iJeeZ4ekI6HDpxPKX2eDq3D5wQTve3uJSDnPvUVYmAw+dgtfsw0aQmSF5wy25L72 ynMEanWyXghGGhjMiqpsuR8hHJzIIVMupGZjiBhtFTKcMB2u5Gu+vZiCCV7SFOQSxTHJ SR3A== X-Gm-Message-State: AOAM533wULV1EcGAbey+iphuj9TWLlWbplxOJEPrLQwrULC9zYE3UY/E dfkmOPKCU/DewxNbAy4O8Q6tsFavgtzQ+cLk9+w= X-Google-Smtp-Source: ABdhPJxINEi8SXY1QylNh4shBkE6Gq8Vr+SqWchoPlt7HdxsOOchTzcYtL8nmzqJwndtrZXRS+dTIYA7WzdoTHlQvKY= X-Received: by 2002:a54:4701:: with SMTP id k1mr10390741oik.175.1590869716951; Sat, 30 May 2020 13:15:16 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 30 May 2020 17:15:05 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > Again as suggested, *please* run 'check_GNU_style.sh' on your patches if > you are not used to GNU code style to fix it. I will set it as a git hook, so I won't be able to commit unless the code is well formatted. > Presenting a patch correctly formatted, well tested and fully understood > is a sign of respect for reviewers and the time they are going to invest > in the review process. > We are all volunteers and we all have to cope with time constraints. > Investing time in reviews means subtracting it to other activities > including working on other patches and features. I have great respect for you and Eli, and for all the time you have spent reviewing my patches. I am sorry that my lack of attention has been taken as a lack respect for you. It will not happen again. > We aim for code quality rather then quantity or other metrics. > The followings are to be considered as basic features we want for all > patches (not just this) to be applied to this branch: > - Compiles and bootstrap --with-nativecomp --without-nativecomp I had setup an AppVeyor instance that compiles my repo without native-comp on Windows. I could not detect the build problems in my latest patch for some unknown reason. I didn't expect that to happen. I will add two instances that build the code on GNU/Linux with and without native-comp, that should help me catch more build errors. > - Formatting is correct > Obviously we can always make mistakes that is totally okay, but does not > have to be a routine that is expected to be fixed by reviewers. > Please apply these suggestions to all patches that are submitted or > pending for review to speed-up the process so we can leave the > discussion for interesting topics. I am really sorry for wasting your time like this. It will not happen again. Nico From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 16:54:56 2020 Received: (at 41242) by debbugs.gnu.org; 30 May 2020 20:54:56 +0000 Received: from localhost ([127.0.0.1]:59285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf8VM-00008R-1P for submit@debbugs.gnu.org; Sat, 30 May 2020 16:54:56 -0400 Received: from mail-ot1-f43.google.com ([209.85.210.43]:42081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jf8VK-00008E-OY for 41242@debbugs.gnu.org; Sat, 30 May 2020 16:54:55 -0400 Received: by mail-ot1-f43.google.com with SMTP id o7so356467oti.9 for <41242@debbugs.gnu.org>; Sat, 30 May 2020 13:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EU817MeJ6sRiwJb++ZfgpYVbiLrGkyViOziQeMkSSHU=; b=TdphYrqLOTAqj4g07c89PdIKhmxFk3yhjcjnopkAPbUzkuS++44zDaMlJuhbNNo+Pc QG0VhYWbuS6Dz07rhUywZqd+IqZXt1TG3x8TofhZU/RZKqf4XW5oX2kRLJzXp6DzpxzF xucJhV45TAqhbZdPbR9Fdn5xpW9JnL6yIo0yXDg6uhqHXIFczvQNfQrAEBRzQubci7Ru Jy/vCt/aaIkntTjtvWdbG4C7pd0Z18BiAGPRCiolzErQflJQXFX49DAX4cAqUkQQTlPd qsbZKr2O/LMEQU6nXz2PRyR+FnSQdPgmg2dv+cWmetLmcrfAbCkB4mhnOZasz4IB6p7L /sJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EU817MeJ6sRiwJb++ZfgpYVbiLrGkyViOziQeMkSSHU=; b=nrAqybEqdepobj0X5m5zDFFkE210Z5LZUFLDMjBwlqVpOgGQqYoI0X12pVlleeeCUC MhA7fkJ+zwMcV6ah0+w1JKMvnczivEjPMG3j3ZF0L8iX55ldJEiFVamFUA/bgvSIInGC +iE/jPAshQ5MgKDZGhrtJsYVUBoZZ+dFcGMNsuoPecQluOwQz85d+INarinPltL5ql/j w90INnUGS8tEZbgo3EPu3W7/juIuvPFZG+YO444XoragR6JRvoFPd4IArzbuQNNl4kWR CcYmDsotgB4UORHxj8QK1KLQbpnEYJ3f0KoiBec5NPiJdDulHWgsvZb/3wupuzkGKFRt 8nrw== X-Gm-Message-State: AOAM530CZqXyUsMUyOFqj9GrigfANSwyrh+tz57cDHIAPTZwcMcDyBRO j5NariiItDCDexW4tmC8q7KxWbRJYEvu74lG+iw= X-Google-Smtp-Source: ABdhPJz7RxGk2sVX1aLbuySy3VbawIeu4rQmI0TCxga9gFGL44J5+lwuCS4i1+5eIA0TcaerGZ9kDYR8HBAbwYSoYeE= X-Received: by 2002:a9d:4c19:: with SMTP id l25mr8821198otf.193.1590872088990; Sat, 30 May 2020 13:54:48 -0700 (PDT) MIME-Version: 1.0 References: <83k10wshvg.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 30 May 2020 17:54:36 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000bfa3b305a6e3c5a2" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000bfa3b305a6e3c5a2 Content-Type: text/plain; charset="UTF-8" I have reformatted the two bug fixes I attached earlier. Nico --000000000000bfa3b305a6e3c5a2 Content-Type: application/octet-stream; name="0001-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Disposition: attachment; filename="0001-Do-not-call-gensym-too-early-when-loading-a-dump-fil.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kau3p2ly0 RnJvbSAwZGIwZjg1N2YzYjE1YjU3YzE0NDU4MzEzMjQyNWExOWNkM2I1NjJmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMTow MzowMCAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMS8yXSBEbyBub3QgY2FsbCBgZ2Vuc3ltJyB0b28g ZWFybHkgd2hlbiBsb2FkaW5nIGEgZHVtcCBmaWxlLgoKVGhpcyBoYXBwZW5lZCB3aGVuIHN1YnIu ZWxuIHdhcyBub3QgdGhlIGZpcnN0IG5hdGl2ZSBjb21waWxhdGlvbiB1bml0CnRvIGJlIGxvYWRl ZC4gcmVnaXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCgpIGlzIGNhbGxlZCB3aGVuIGxvYWRpbmcgYQpu YXRpdmUgY29tcGlsYXRpb24gdW5pdCBhbmQgdGhhdCBpbiB0dXJuIHVzZWQgdG8gY2FsbCBgZ2Vu c3ltJywgd2hpY2gKd2FzIG5vdCBsb2FkZWQgeWV0LiBUaGlzIGxlZCB0byBhIFNJR1NFR1YuCgoq IHNyYy9jb21wLmMgKHJlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQpOiBSZXBsYWNlIHRoZSBjYWxs IHRvIGBnZW5zeW0nCndpdGggYW4gYWQtaG9jIGNvdW50ZXIuCi0tLQogc3JjL2NvbXAuYyB8IDcg KysrKysrLQogMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoK ZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29tcC5jCmluZGV4IDMyYTk4MTczZDUuLmQz YmZmMWU0Y2YgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMKKysrIGIvc3JjL2NvbXAuYwpAQCAtNDEy MCw3ICs0MTIwLDEyIEBAIGZpbmlzaF9kZWxheWVkX2Rpc3Bvc2FsX29mX2NvbXBfdW5pdHMgKHZv aWQpCiByZWdpc3Rlcl9uYXRpdmVfY29tcF91bml0IChMaXNwX09iamVjdCBjb21wX3UpCiB7CiAj aWZkZWYgV0lORE9XU05UCi0gIEZwdXRoYXNoIChDQUxMMUkgKGdlbnN5bSwgUW5pbCksIGNvbXBf dSwgYWxsX2xvYWRlZF9jb21wX3VuaXRzX2gpOworICAvKiBXZSBoYXZlIHRvIGRvIHRoaXMgc2lu Y2Ugd2UgY2FuJ3QgdXNlIGBnZW5zeW0nLiBUaGlzIGZ1bmN0aW9uIGlzCisgICAgIGNhbGxlZCBl YXJseSB3aGVuIGxvYWRpbmcgYSBkdW1wIGZpbGUgYW5kIHN1YnIuZWwgbWF5IG5vdCBoYXZlCisg ICAgIGJlZW4gbG9hZGVkIHlldC4gICovCisgIHN0YXRpYyBpbnRtYXhfdCBjb3VudDsKKworICBG cHV0aGFzaCAobWFrZV9pbnQgKGNvdW50KyspLCBjb21wX3UsIGFsbF9sb2FkZWRfY29tcF91bml0 c19oKTsKICNlbmRpZgogfQogCi0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000bfa3b305a6e3c5a2 Content-Type: application/octet-stream; name="0002-Fix-loading-of-libgccjit.dll-while-dumping-in-Window.patch" Content-Disposition: attachment; filename="0002-Fix-loading-of-libgccjit.dll-while-dumping-in-Window.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kau3p2qe1 RnJvbSA4N2FjNzllOTU4YmQ1NjU4Y2RjNTBlY2E3NDdiZTg2OTlmNDZhY2M3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogRnJpLCAyOSBNYXkgMjAyMCAyMTow ODozNyAtMDMwMApTdWJqZWN0OiBbUEFUQ0ggMi8yXSBGaXggbG9hZGluZyBvZiBsaWJnY2NqaXQu ZGxsIHdoaWxlIGR1bXBpbmcgaW4gV2luZG93cy4KCmxvYWR1cC5lbCBjYWxscyBgbmF0aXZlLWNv bXAtYXZhaWxhYmxlLXAnLCB0aGF0IGNhbGxzCmxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSgpIGlu IFdpbmRvd3MuIFRoYXQgZnVuY3Rpb24gdHJpZXMgdG8gbG9hZApsaWJnY2NqaXQgdXNpbmcgdGhl IG1hcHBpbmdzIGRlZmluZWQgaW4gYGR5bmFtaWMtbGlicmFyeS1hbGlzdCcuIFRoYXQKbWFwcGlu ZyBpcyBmaWxsZWQgYnkgdGVybS93MzItd2luLmVsLCBidXQgdGhhdCBmaWxlIG1heSBiZSBsb2Fk ZWQgdG9vCmxhdGUuCgoqIHNyYy9lbWFjcy5jIChzeW1zX29mX2VtYWNzKTogQWRkIGxpYmdjY2pp dCB0byB0aGUKYGR5bmFtaWMtbGlicmFyeS1hbGlzdCcgdXNlZCB3aGVuIHN0YXJ0aW5nIHRvIGR1 bXAgc28KYG5hdGl2ZS1jb21wLWF2YWlsYWJsZS1wJyBhbHdheXMgd29ya3MgaW4gV2luZG93cy4K LS0tCiBzcmMvZW1hY3MuYyB8IDExICsrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMTEgaW5z ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy5jIGIvc3JjL2VtYWNzLmMKaW5kZXgg MzVhZTlkMGU2Ni4uNmM4NjkzMWQyYiAxMDA2NDQKLS0tIGEvc3JjL2VtYWNzLmMKKysrIGIvc3Jj L2VtYWNzLmMKQEAgLTMwNTMsNyArMzA1MywxOCBAQCBzeW1zX29mX2VtYWNzICh2b2lkKQogCiBB bHNvIG5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhIGdlbmVyaWMgZmFjaWxpdHkgZm9yIGFjY2Vzc2lu ZyBleHRlcm5hbAogbGlicmFyaWVzOyBvbmx5IHRob3NlIGFscmVhZHkga25vd24gYnkgRW1hY3Mg d2lsbCBiZSBsb2FkZWQuICAqLyk7CisjaWZkZWYgV0lORE9XU05UCisgIC8qIFdlIG1heSBuZWVk IHRvIGxvYWQgbGliZ2Njaml0IHdoZW4gZHVtcGluZyBiZWZvcmUgdGVybS93MzItd2luLmVsCisg ICAgIGRlZmluZXMgYGR5bmFtaWMtbGlicmFyeS1hbGlzdGAuIFRoaXMgd2lsbCBmYWlsIGlmIHRo YXQgdmFyaWFibGUKKyAgICAgaXMgZW1wdHksIHNvIGFkZCBsaWJnY2NqaXQuZGxsIHRvIGl0LiAg Ki8KKyAgaWYgKHdpbGxfZHVtcF9wICgpKQorICAgIFZkeW5hbWljX2xpYnJhcnlfYWxpc3QgPSBs aXN0MSAobGlzdDIgKFFnY2NqaXQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYnVpbGRfc3RyaW5nICgibGliZ2Njaml0LmRsbCIpKSk7CisgIGVsc2UKKyAgICBW ZHluYW1pY19saWJyYXJ5X2FsaXN0ID0gUW5pbDsKKyNlbHNlCiAgIFZkeW5hbWljX2xpYnJhcnlf YWxpc3QgPSBRbmlsOworI2VuZGlmCiAgIEZwdXQgKGludGVybl9jX3N0cmluZyAoImR5bmFtaWMt bGlicmFyeS1hbGlzdCIpLCBRcmlza3lfbG9jYWxfdmFyaWFibGUsIFF0KTsKIAogI2lmZGVmIFdJ TkRPV1NOVAotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000bfa3b305a6e3c5a2-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 31 04:55:18 2020 Received: (at 41242) by debbugs.gnu.org; 31 May 2020 08:55:18 +0000 Received: from localhost ([127.0.0.1]:59704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfJkU-0002YC-7s for submit@debbugs.gnu.org; Sun, 31 May 2020 04:55:18 -0400 Received: from mx.sdf.org ([205.166.94.20]:65203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfJkR-0002Y2-Qr for 41242@debbugs.gnu.org; Sun, 31 May 2020 04:55:16 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04V8tCvQ012735 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 31 May 2020 08:55:13 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04V8tCAY006648; Sun, 31 May 2020 08:55:12 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Determine the emacs root dir... References: <83k10wshvg.fsf@gnu.org> Date: Sun, 31 May 2020 08:55:12 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 30 May 2020 17:54:36 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > I have reformatted the two bug fixes I attached earlier. Appreciated, I've applied the two. Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sun May 31 11:34:37 2020 Received: (at 41242) by debbugs.gnu.org; 31 May 2020 15:34:37 +0000 Received: from localhost ([127.0.0.1]:33625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfPyv-0006Ki-0X for submit@debbugs.gnu.org; Sun, 31 May 2020 11:34:37 -0400 Received: from mail-ot1-f42.google.com ([209.85.210.42]:34963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfPyt-0006KU-0W for 41242@debbugs.gnu.org; Sun, 31 May 2020 11:34:36 -0400 Received: by mail-ot1-f42.google.com with SMTP id 69so5987432otv.2 for <41242@debbugs.gnu.org>; Sun, 31 May 2020 08:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g8ve+4xIvansnywLYywcTPMldoY1QPd4WbgksOP3YHk=; b=Ora1Ch9eIqIljo8fzMmRdS0neGAYx1cWYnEnSABBdISYmnPR2H5HSxBVipwju3v/Jl /jFPPdwQ/wKFmSCnGmLFtQaIuSBTOWNZXuE313Z6XQXhY2xFU5jnYzKSqbACRRJ4rKxO zW3lw6iZPaQTNmmsutmLG6sUbAUI0FN/wg958DOebO5kqJiU9drEB/37eRPDMOzMZITO KsKtW8kxOdQsXuL5VMlO80hkOOSWLjYrYa8EJjrPEljUnyspzff4kbXt8rqBbk48+ZT1 P2cmlYYHxBl0oJuGTj2F2NY+fr50vPSg5SEegJprnpa3ypTknubP8rr2OV7xws2eQzdW nceA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g8ve+4xIvansnywLYywcTPMldoY1QPd4WbgksOP3YHk=; b=fKCyu4gqLXBYi2Z3TBYYBFR4lrbF/3SxLicO9QLoRbGSE0zLDvtQ/qiQQrJGg0m5xz HljFGefTI+Bu4AwS2mCNUyd5n+MSTMwlCzBg1XYMDQX2yLfFbF2vlQQSGU+oX/yhwVaA hgpP5neTbTSiXbvMxY7FIaMW1823GQxYGd90ffxeyZlAnMQnWnsaVaVWp+dZrzjgKtw6 GXMRaplhnZH7Sqzb2xBfMSSGWhiCjfFXU7e/pT72t7vPxEw/bMETz9HQMleCy1TGOQyf A/1RpDC0nnGbGtQyyAN8BUd+62uqdy7n02iuIEPV7gHHCNIqvBxGuBbAjGdy820XTZRN 2KwQ== X-Gm-Message-State: AOAM533wsDj5uaDUk1rjyT06z93MmZ1G24f4cZii0ra/XNqvwm3EEwBc blMQdv3YLT+8CEA4bbBW8be1HyKrcZPts1JVCkg= X-Google-Smtp-Source: ABdhPJywZlCOcCjhnsChBK4RhB6Hq9eUrDWJYarQyQEFYLlbP9pBv+V0t+gh6PjmPaWeS0X8WjC2UGW+GkXLDFuzTH8= X-Received: by 2002:a05:6830:2439:: with SMTP id k25mr12940324ots.352.1590939269245; Sun, 31 May 2020 08:34:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sun, 31 May 2020 12:34:16 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: multipart/mixed; boundary="00000000000000d42205a6f36a4c" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --00000000000000d42205a6f36a4c Content-Type: text/plain; charset="UTF-8" Hi Andrea, > I could not compile this patch because non all the calls to openp has > been updated for the new parameter (my question on adding this stands). Sorry. I didn't check the GNU/Linux build. > In general please recall to check the stock build when working on > infrastructure integration, it's quite easy to break. I have tested that this new patch builds and bootstraps in windows x64, Ubuntu 18.04 amd64. Both with and without nativecomp. > Generally speaking I think the behavior we want to have is that when a > .eln file is specified this is loaded without re-adding > Vcomp_native_path_postfix. I could not test it but I suspect this is > not handled. I tested moving company.eln to a directory in load-path without `comp-native-path-postfix` and then ran (load "company.eln") and it was loaded from that directory. Nico. --00000000000000d42205a6f36a4c Content-Type: application/octet-stream; name="0001-Reduce-the-number-of-files-probed-when-finding-a-lis.patch" Content-Disposition: attachment; filename="0001-Reduce-the-number-of-files-probed-when-finding-a-lis.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kav7th660 RnJvbSBkNjU5YThhN2VkOTkxOGQ3YTc3NjU1MTA5YWJjNmRiNTMzOGFjMzU0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAyNSBNYXkgMjAyMCAxODow NToyMyAtMDMwMApTdWJqZWN0OiBbUEFUQ0hdIFJlZHVjZSB0aGUgbnVtYmVyIG9mIGZpbGVzIHBy b2JlZCB3aGVuIGZpbmRpbmcgYSBsaXNwIGZpbGUuCgoqIHNyYy9scmVhZC5jIChnZXQtbG9hZC1z dWZmaXhlcyk6IERvIG5vdCBhZGQgYW55IHN1ZmZpeCB0byBmaWxlcyB0aGF0Cm5lZWQgdG8gYmUg bG9hZGVkIGJ5IHRoZSBkeW5hbWljIGxpbmtlci4KKGVmZmVjdGl2ZV9sb2FkX3BhdGgpOiBSZW1v dmUgZnVuY3Rpb24uCihsb2FkKTogRG9uJ3QgYWRkIGFueSBzdWZmaXggaWYgZmlsZSBlbmRzIGlu IGEgc3VmZml4IGFscmVhZHkuCihlZmZlY3RpdmVfbG9hZF9wYXRoKTogUmVtb3ZlIGZ1bmN0aW9u Lgoob3BlbnBfYWRkX21pZGRsZV9kaXJfdG9fc3VmZml4ZXMpOiBBZGQgaGVscGVyIGZ1bmN0aW9u IHRvIGNyZWF0ZQpwYWlycyBvZiBtaWRkbGUgZGlyZWN0b3JpZXMgYW5kIHN1ZmZpeGVzLgoob3Bl bnBfbWF4X21pZGRsZWRpcl9hbmRfc3VmZml4X2xlbik6IEFkZCBoZWxwZXIgZnVuY3Rpb24gdG8g Y291bnQgdGhlCm51bWJlciBvZiBieXRlcyBuZWVkZWQgdG8gc3RvcmUgdGhlIG1pZGRsZSBkaXJl Y3RvcnkgYW5kIHN1ZmZpeC4KKG9wZW5wX2ZpbGxfZmlsZW5hbWVfYnVmZmVyKTogQWRkIGhlbHBl ciBmdW5jdGlvbiB0byBjb3B5IG1pZGRsZQpkaXJlY3RvcnksIGJhc2VuYW1lIGFuZCBzdWZmaXgg dG8gdGhlIGZpbGVuYW1lIGJ1ZmZlci4KLS0tCiBzcmMvbHJlYWQuYyB8IDIwMyArKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdl ZCwgMTU0IGluc2VydGlvbnMoKyksIDQ5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9s cmVhZC5jIGIvc3JjL2xyZWFkLmMKaW5kZXggOWY4NDllZGE0Mi4uYzY2NjZlNGVhMyAxMDA2NDQK LS0tIGEvc3JjL2xyZWFkLmMKKysrIGIvc3JjL2xyZWFkLmMKQEAgLTEwNTYsMzEgKzEwNTYsMjUg QEAgREVGVU4gKCJnZXQtbG9hZC1zdWZmaXhlcyIsIEZnZXRfbG9hZF9zdWZmaXhlcywgU2dldF9s b2FkX3N1ZmZpeGVzLCAwLCAwLCAwLAogICAgIHsKICAgICAgIExpc3BfT2JqZWN0IGV4dHMgPSBW bG9hZF9maWxlX3JlcF9zdWZmaXhlczsKICAgICAgIExpc3BfT2JqZWN0IHN1ZmZpeCA9IFhDQVIg KHN1ZmZpeGVzKTsKLSAgICAgIEZPUl9FQUNIX1RBSUwgKGV4dHMpCi0JbHN0ID0gRmNvbnMgKGNv bmNhdDIgKHN1ZmZpeCwgWENBUiAoZXh0cykpLCBsc3QpOwotICAgIH0KLSAgcmV0dXJuIEZucmV2 ZXJzZSAobHN0KTsKLX0KKyAgICAgIGJvb2wgbmF0aXZlX2NvZGVfc3VmZml4ID0gKE5BVElWRV9D T01QX0ZMQUcKKyAgICAgICAgJiYgc3RyY21wIChOQVRJVkVfRUxJU1BfU1VGRklYLCBTU0RBVEEg KHN1ZmZpeCkpID09IDApOwogCi1zdGF0aWMgTGlzcF9PYmplY3QKLWVmZmVjdGl2ZV9sb2FkX3Bh dGggKHZvaWQpCi17Ci0jaWZuZGVmIEhBVkVfTkFUSVZFX0NPTVAKLSAgcmV0dXJuIFZsb2FkX3Bh dGg7Ci0jZWxzZQotICBMaXNwX09iamVjdCBscCA9IFZsb2FkX3BhdGg7Ci0gIExpc3BfT2JqZWN0 IG5ld19scCA9IFFuaWw7Ci0gIEZPUl9FQUNIX1RBSUwgKGxwKQotICAgIHsKLSAgICAgIExpc3Bf T2JqZWN0IGVsID0gWENBUiAobHApOwotICAgICAgbmV3X2xwID0KLQlGY29ucyAoY29uY2F0MiAo RmZpbGVfbmFtZV9hc19kaXJlY3RvcnkgKGVsKSwKLQkJCVZjb21wX25hdGl2ZV9wYXRoX3Bvc3Rm aXgpLAotCSAgICAgICBuZXdfbHApOwotICAgICAgbmV3X2xwID0gRmNvbnMgKGVsLCBuZXdfbHAp OwotICAgIH0KLSAgcmV0dXJuIEZucmV2ZXJzZSAobmV3X2xwKTsKKyNpZmRlZiBIQVZFX01PRFVM RVMKKyAgICAgIG5hdGl2ZV9jb2RlX3N1ZmZpeCA9IG5hdGl2ZV9jb2RlX3N1ZmZpeAorICAgICAg ICB8fCBzdHJjbXAgKE1PRFVMRVNfU1VGRklYLCBTU0RBVEEgKHN1ZmZpeCkpID09IDA7CisjaWZk ZWYgTU9EVUxFU19TRUNPTkRBUllfU1VGRklYCisgICAgICBuYXRpdmVfY29kZV9zdWZmaXggPSBu YXRpdmVfY29kZV9zdWZmaXgKKyAgICAgICAgfHwgc3RyY21wIChNT0RVTEVTX1NFQ09OREFSWV9T VUZGSVgsIFNTREFUQSAoc3VmZml4KSkgPT0gMDsKKyNlbmRpZgogI2VuZGlmCisKKyAgICAgIGlm IChuYXRpdmVfY29kZV9zdWZmaXgpCisJbHN0ID0gRmNvbnMgKHN1ZmZpeCwgbHN0KTsKKyAgICAg IGVsc2UKKyAgICAgICAgRk9SX0VBQ0hfVEFJTCAoZXh0cykKKyAgICAgICAgICBsc3QgPSBGY29u cyAoY29uY2F0MiAoc3VmZml4LCBYQ0FSIChleHRzKSksIGxzdCk7CisgICAgfQorICByZXR1cm4g Rm5yZXZlcnNlIChsc3QpOwogfQogCiAvKiBSZXR1cm4gdHJ1ZSBpZiBTVFJJTkcgZW5kcyB3aXRo IFNVRkZJWC4gICovCkBAIC0xMjE4LDcgKzEyMTIsNyBAQCBERUZVTiAoImxvYWQiLCBGbG9hZCwg U2xvYWQsIDEsIDUsIDAsCiAgICAgICAgICAgICAgIHx8IHN1ZmZpeF9wIChmaWxlLCBNT0RVTEVT X1NFQ09OREFSWV9TVUZGSVgpCiAjZW5kaWYKICNlbmRpZgotCSAgICAgICkKKyAgICAgICAgICAg ICAgfHwgKE5BVElWRV9DT01QX0ZMQUcgJiYgc3VmZml4X3AgKGZpbGUsIE5BVElWRV9FTElTUF9T VUZGSVgpKSkKIAkgICAgbXVzdF9zdWZmaXggPSBRbmlsOwogCSAgLyogRG9uJ3QgaW5zaXN0IG9u IGFkZGluZyBhIHN1ZmZpeAogCSAgICAgaWYgdGhlIGFyZ3VtZW50IGluY2x1ZGVzIGEgZGlyZWN0 b3J5IG5hbWUuICAqLwpAQCAtMTIzNiw4ICsxMjMwLDcgQEAgREVGVU4gKCJsb2FkIiwgRmxvYWQs IFNsb2FkLCAxLCA1LCAwLAogCX0KIAogICAgICAgZmQgPQotCW9wZW5wIChlZmZlY3RpdmVfbG9h ZF9wYXRoICgpLCBmaWxlLCBzdWZmaXhlcywgJmZvdW5kLCBRbmlsLAotCSAgICAgICBsb2FkX3By ZWZlcl9uZXdlcik7CisJb3BlbnAgKFZsb2FkX3BhdGgsIGZpbGUsIHN1ZmZpeGVzLCAmZm91bmQs IFFuaWwsIGxvYWRfcHJlZmVyX25ld2VyKTsKICAgICB9CiAKICAgaWYgKGZkID09IC0xKQpAQCAt MTYwNiw2ICsxNTk5LDExNiBAQCBERUZVTiAoImxvY2F0ZS1maWxlLWludGVybmFsIiwgRmxvY2F0 ZV9maWxlX2ludGVybmFsLCBTbG9jYXRlX2ZpbGVfaW50ZXJuYWwsIDIsCiAgIHJldHVybiBmaWxl OwogfQogCisvKiBUaGlzIGZ1bmN0aW9uIHR1cm5zIGEgbGlzdCBvZiBzdWZmaXhlcyBpbnRvIGEg bGlzdCBvZiBtaWRkbGUgZGlycworICAgYW5kIHN1ZmZpeGVzLiAgSWYgdGhlIHN1ZmZpeCBpcyBu b3QgTkFUSVZFX0VMSVNQX1NVRkZJWCB0aGVuIGl0cworICAgc3VmZml4IGlzIG5pbCBhbmQgaXQg aXMgYWRkZWQgdG8gdGhlIGxpc3QgYXMgaXMuICBJbnN0ZWFkLCBpZiBpdAorICAgc3VmZml4IGlz IE5BVElWRV9FTElTUF9TVUZGSVggdGhlbiB0d28gZWxlbWVudHMgYXJlIGFkZGVkIHRvIHRoZQor ICAgbGlzdC4gIFRoZSBmaXJzdCBvbmUgaGFzIG1pZGRsZWRpciBlcXVhbCB0byBuaWwgYW5kIHRo ZSBzZWNvbmQgdXNlcworICAgY29tcC1uYXRpdmUtcGF0aC1wb3N0Zml4IGFzIG1pZGRsZWRpci4g IFRoaXMgaXMgYmVjYXVzZSB3ZSdkIGxpa2UKKyAgIHRvIHNlYXJjaCBmb3IgZGlyL2Zvby5lbG4g YmVmb3JlIGRpci9taWRkbGVkaXIvZm9vLmVsbi4KKworRm9yIGV4YW1wbGUsIGl0IHR1cm5zIHRo aXM6CisKKygiLmVsbiIgIi5lbGMiICIuZWxjLmd6IiAiLmVsIiAiLmVsLmd6IikKKworIGludG8g dGhpczoKKworKChuaWwgLiAiLmVsbiIpCisgKGNvbXAtbmF0aXZlLXBhdGgtcG9zdGZpeCAuICIu ZWxuIikKKyAobmlsIC4gIi5lbGMiKQorIChuaWwgLiAiLmVsYy5neiIpCisgKG5pbCAuICIuZWwi KQorIChuaWwgLiAiLmVsLmd6IikpCisqLworc3RhdGljIExpc3BfT2JqZWN0CitvcGVucF9hZGRf bWlkZGxlX2Rpcl90b19zdWZmaXhlcyAoTGlzcF9PYmplY3Qgc3VmZml4ZXMpCit7CisgIExpc3Bf T2JqZWN0IHRhaWwgPSBzdWZmaXhlczsKKyAgTGlzcF9PYmplY3QgZXh0ZW5kZWRfc3VmID0gUW5p bDsKKyAgRk9SX0VBQ0hfVEFJTF9TQUZFICh0YWlsKQorICAgIHsKKyNpZmRlZiBIQVZFX05BVElW RV9DT01QCisgICAgICBDSEVDS19TVFJJTkdfQ0FSICh0YWlsKTsKKyAgICAgIGNoYXIgKiBzdWYg PSBTU0RBVEEgKFhDQVIgKHRhaWwpKTsKKyAgICAgIGlmIChzdHJjbXAgKE5BVElWRV9FTElTUF9T VUZGSVgsIHN1ZikgPT0gMCkKKyAgICAgICAgeworICAgICAgICAgIENIRUNLX1NUUklORyAoVmNv bXBfbmF0aXZlX3BhdGhfcG9zdGZpeCk7CisgICAgICAgICAgLyogSGVyZSB3ZSBhZGQgdGhlbSBp biB0aGUgb3Bwb3NpdGUgb3JkZXIgc28gdGhhdCBucmV2ZXJzZQorICAgICAgICAgICAgIGNvcnJl Y3RzIGl0LiAgKi8KKyAgICAgICAgICBleHRlbmRlZF9zdWYgPSBGY29ucyAoRmNvbnMgKFFuaWws IFhDQVIgKHRhaWwpKSwgZXh0ZW5kZWRfc3VmKTsKKyAgICAgICAgICBleHRlbmRlZF9zdWYgPSBG Y29ucyAoRmNvbnMgKFZjb21wX25hdGl2ZV9wYXRoX3Bvc3RmaXgsIFhDQVIgKHRhaWwpKSwKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5kZWRfc3VmKTsKKyAgICAgICAgfQor ICAgICAgZWxzZQorI2VuZGlmCisgICAgICAgIHsKKyAgICAgICAgICBleHRlbmRlZF9zdWYgPSBG Y29ucyAoRmNvbnMgKFFuaWwsIFhDQVIgKHRhaWwpKSwgZXh0ZW5kZWRfc3VmKTsKKyAgICAgICAg fQorICAgIH0KKworICBzdWZmaXhlcyA9IEZucmV2ZXJzZSAoZXh0ZW5kZWRfc3VmKTsKKyAgcmV0 dXJuIHN1ZmZpeGVzOworfQorCisvKiAgVGhpcyBmdW5jdGlvbiB0YWtlcyBhIGxpc3Qgb2YgbWlk ZGxlZGlycyBhbmQgc3VmZml4ZXMgYW5kIHJldHVybnMKKyAgICB0aGUgbWF4aW11bSBidWZmZXIg c3BhY2UgdGhhdCB0aGlzIHBhcnQgb2YgdGhlIGZpbGVuYW1lIHdpbGwKKyAgICBuZWVkLiAgKi8K K3N0YXRpYyBwdHJkaWZmX3QKK29wZW5wX21heF9taWRkbGVkaXJfYW5kX3N1ZmZpeF9sZW4gKExp c3BfT2JqZWN0IG1pZGRsZWRpcl9hbmRfc3VmZml4ZXMpCit7CisgIHB0cmRpZmZfdCBtYXhfZXh0 cmFfbGVuID0gMDsKKyAgTGlzcF9PYmplY3QgdGFpbCA9IG1pZGRsZWRpcl9hbmRfc3VmZml4ZXM7 CisgIEZPUl9FQUNIX1RBSUxfU0FGRSAodGFpbCkKKyAgICB7CisgICAgICBMaXNwX09iamVjdCBt aWRkbGVkaXJfYW5kX3N1ZmZpeCA9IFhDQVIgKHRhaWwpOworICAgICAgTGlzcF9PYmplY3QgbWlk ZGxlZGlyID0gWENBUiAobWlkZGxlZGlyX2FuZF9zdWZmaXgpOworICAgICAgTGlzcF9PYmplY3Qg c3VmZml4ID0gWENEUiAobWlkZGxlZGlyX2FuZF9zdWZmaXgpOworICAgICAgcHRyZGlmZl90IGxl biA9IFNCWVRFUyAoc3VmZml4KTsKKyAgICAgIGlmICghTklMUCAobWlkZGxlZGlyKSkKKyAgICAg ICAgICBsZW4gKz0gMiArIFNCWVRFUyAobWlkZGxlZGlyKTsgLyogQWRkIHR3byBzbGFzaGVzLiAg Ki8KKyAgICAgIG1heF9leHRyYV9sZW4gPSBtYXggKG1heF9leHRyYV9sZW4sIGxlbik7CisgICAg fQorICByZXR1cm4gbWF4X2V4dHJhX2xlbjsKK30KKworLyogIFRoaXMgZnVuY3Rpb24gY29tcGxl dGVzIHRoZSBGTiBidWZmZXIgd2l0aCB0aGUgbWlkZGxlZGlyLAorICAgIGJhc2VuYW1lbWUsIGFu ZCBzdWZmaXguICBJdCB0YWtlcyB0aGUgZGlyZWN0b3J5IGxlbmd0aCBpbiBESVJOQU1FLAorICAg IGJ1dCBpdCByZXF1aXJlcyB0aGF0IGl0IGhhcyBiZWVuIGNvcGllZCBhbHJlYWR5IHRvIHRoZSBz dGFydCBvZgorICAgIHRoZSBidWZmZXIuCisKKyAgICBBZnRlciB0aGlzIGZ1bmN0aW9uIHRoZSBG TiBidWZmZXIgd2lsbCBiZSAoZGVwZW5kaW5nIG9uIG1pZGRsZWRpcikKKyAgICBkaXJuYW1lL21p ZGRsZWRpci9iYXNlbmFtZS5zdWZmaXgKKyAgICBvcgorICAgIGRpcm5hbWUvYmFzZW5hbWUuc3Vm Zml4CisqLworc3RhdGljIHB0cmRpZmZfdAorb3BlbnBfZmlsbF9maWxlbmFtZV9idWZmZXIgKGNo YXIgKmZuLCBwdHJkaWZmX3QgZGlybmFtZWxlbiwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICBMaXNwX09iamVjdCBiYXNlbmFtZXdleHQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg TGlzcF9PYmplY3QgbWlkZGxlZGlyX2FuZF9zdWZmaXgpCit7CisgIExpc3BfT2JqZWN0IG1pZGRs ZWRpciA9IFhDQVIgKG1pZGRsZWRpcl9hbmRfc3VmZml4KTsKKyAgTGlzcF9PYmplY3Qgc3VmZml4 ID0gWENEUiAobWlkZGxlZGlyX2FuZF9zdWZmaXgpOworICBwdHJkaWZmX3QgYmFzZW5hbWV3ZXh0 X2xlbiA9IFNCWVRFUyAoYmFzZW5hbWV3ZXh0KTsKKyAgcHRyZGlmZl90IGZubGVuLCBsc3VmZml4 ID0gU0JZVEVTIChzdWZmaXgpOworICBwdHJkaWZmX3QgbG1pZGRsZWRpciA9IDA7CisgIGlmICgh TklMUCAobWlkZGxlZGlyKSkKKyAgICB7CisgICAgICAvKiBBZGQgMSBmb3IgdGhlIHNsYXNoLiAg Ki8KKyAgICAgIGxtaWRkbGVkaXIgPSBTQllURVMgKG1pZGRsZWRpcikgKyAxOworICAgICAgbWVt Y3B5IChmbiArIGRpcm5hbWVsZW4sIFNEQVRBIChtaWRkbGVkaXIpLAorICAgICAgICAgICAgICBs bWlkZGxlZGlyIC0gMSk7CisgICAgICBmbltkaXJuYW1lbGVuICsgKGxtaWRkbGVkaXIgLSAxKV0g PSAnLyc7CisgICAgfQorCisgIG1lbWNweSAoZm4gKyBkaXJuYW1lbGVuICsgbG1pZGRsZWRpciwg U0RBVEEgKGJhc2VuYW1ld2V4dCksCisgICAgICAgICAgYmFzZW5hbWV3ZXh0X2xlbik7CisgIC8q IE1ha2UgY29tcGxldGUgZmlsZW5hbWUgYnkgYXBwZW5kaW5nIFNVRkZJWC4gICovCisgIG1lbWNw eSAoZm4gKyBkaXJuYW1lbGVuICsgbG1pZGRsZWRpciArIGJhc2VuYW1ld2V4dF9sZW4sCisgICAg ICAgICAgU0RBVEEgKHN1ZmZpeCksIGxzdWZmaXggKyAxKTsKKyAgZm5sZW4gPSBkaXJuYW1lbGVu ICsgbG1pZGRsZWRpciArIGJhc2VuYW1ld2V4dF9sZW4gKyBsc3VmZml4OworICByZXR1cm4gZm5s ZW47Cit9CisKIC8qIFNlYXJjaCBmb3IgYSBmaWxlIHdob3NlIG5hbWUgaXMgU1RSLCBsb29raW5n IGluIGRpcmVjdG9yaWVzCiAgICBpbiB0aGUgTGlzcCBsaXN0IFBBVEgsIGFuZCB0cnlpbmcgc3Vm Zml4ZXMgZnJvbSBTVUZGSVguCiAgICBPbiBzdWNjZXNzLCByZXR1cm4gYSBmaWxlIGRlc2NyaXB0 b3IgKG9yIDEgb3IgLTIgYXMgZGVzY3JpYmVkIGJlbG93KS4KQEAgLTE2NDMsNyArMTc0Niw4IEBA IG9wZW5wIChMaXNwX09iamVjdCBwYXRoLCBMaXNwX09iamVjdCBzdHIsIExpc3BfT2JqZWN0IHN1 ZmZpeGVzLAogICBwdHJkaWZmX3Qgd2FudF9sZW5ndGg7CiAgIExpc3BfT2JqZWN0IGZpbGVuYW1l OwogICBMaXNwX09iamVjdCBzdHJpbmcsIHRhaWwsIGVuY29kZWRfZm4sIHNhdmVfc3RyaW5nOwot ICBwdHJkaWZmX3QgbWF4X3N1ZmZpeF9sZW4gPSAwOworICBMaXNwX09iamVjdCBtaWRkbGVkaXJf YW5kX3N1ZmZpeGVzOworICBwdHJkaWZmX3QgbWF4X2V4dHJhX2xlbiA9IDA7CiAgIGludCBsYXN0 X2Vycm5vID0gRU5PRU5UOwogICBpbnQgc2F2ZV9mZCA9IC0xOwogICBVU0VfU0FGRV9BTExPQ0E7 CkBAIC0xNjU0LDEzICsxNzU4LDkgQEAgb3BlbnAgKExpc3BfT2JqZWN0IHBhdGgsIExpc3BfT2Jq ZWN0IHN0ciwgTGlzcF9PYmplY3Qgc3VmZml4ZXMsCiAKICAgQ0hFQ0tfU1RSSU5HIChzdHIpOwog Ci0gIHRhaWwgPSBzdWZmaXhlczsKLSAgRk9SX0VBQ0hfVEFJTF9TQUZFICh0YWlsKQotICAgIHsK LSAgICAgIENIRUNLX1NUUklOR19DQVIgKHRhaWwpOwotICAgICAgbWF4X3N1ZmZpeF9sZW4gPSBt YXggKG1heF9zdWZmaXhfbGVuLAotCQkJICAgIFNCWVRFUyAoWENBUiAodGFpbCkpKTsKLSAgICB9 CisgIG1pZGRsZWRpcl9hbmRfc3VmZml4ZXMgPSBvcGVucF9hZGRfbWlkZGxlX2Rpcl90b19zdWZm aXhlcyAoc3VmZml4ZXMpOworCisgIG1heF9leHRyYV9sZW4gPSBvcGVucF9tYXhfbWlkZGxlZGly X2FuZF9zdWZmaXhfbGVuIChtaWRkbGVkaXJfYW5kX3N1ZmZpeGVzKTsKIAogICBzdHJpbmcgPSBm aWxlbmFtZSA9IGVuY29kZWRfZm4gPSBzYXZlX3N0cmluZyA9IFFuaWw7CiAKQEAgLTE2NzcsNyAr MTc3Nyw3IEBAIG9wZW5wIChMaXNwX09iamVjdCBwYXRoLCBMaXNwX09iamVjdCBzdHIsIExpc3Bf T2JqZWN0IHN1ZmZpeGVzLAogICAgICBleGVjdXRhYmxlLiAqLwogICBGT1JfRUFDSF9UQUlMX1NB RkUgKHBhdGgpCiAgICB7Ci0gICAgcHRyZGlmZl90IGJhc2VsZW4sIHByZWZpeGxlbjsKKyAgICBw dHJkaWZmX3QgZGlybmFtZWxlbiwgcHJlZml4bGVuOwogCiAgICAgaWYgKEVRIChwYXRoLCBqdXN0 X3VzZV9zdHIpKQogICAgICAgZmlsZW5hbWUgPSBzdHI7CkBAIC0xNjk0LDM1ICsxNzk0LDQwIEBA IG9wZW5wIChMaXNwX09iamVjdCBwYXRoLCBMaXNwX09iamVjdCBzdHIsIExpc3BfT2JqZWN0IHN1 ZmZpeGVzLAogCSAgY29udGludWU7CiAgICAgICB9CiAKKwogICAgIC8qIENhbGN1bGF0ZSBtYXhp bXVtIGxlbmd0aCBvZiBhbnkgZmlsZW5hbWUgbWFkZSBmcm9tCiAgICAgICAgdGhpcyBwYXRoIGVs ZW1lbnQvc3BlY2lmaWVkIGZpbGUgbmFtZSBhbmQgYW55IHBvc3NpYmxlIHN1ZmZpeC4gICovCi0g ICAgd2FudF9sZW5ndGggPSBtYXhfc3VmZml4X2xlbiArIFNCWVRFUyAoZmlsZW5hbWUpOworICAg IHdhbnRfbGVuZ3RoID0gbWF4X2V4dHJhX2xlbiArIFNCWVRFUyAoZmlsZW5hbWUpOwogICAgIGlm IChmbl9zaXplIDw9IHdhbnRfbGVuZ3RoKQogICAgICAgewogCWZuX3NpemUgPSAxMDAgKyB3YW50 X2xlbmd0aDsKIAlmbiA9IFNBRkVfQUxMT0NBIChmbl9zaXplKTsKICAgICAgIH0KIAorICAgIExp c3BfT2JqZWN0IGRpcm5hbWV3c2xhc2ggPSBGZmlsZV9uYW1lX2RpcmVjdG9yeSAoZmlsZW5hbWUp OworICAgIExpc3BfT2JqZWN0IGJhc2VuYW1ld2V4dCA9IEZmaWxlX25hbWVfbm9uZGlyZWN0b3J5 IChmaWxlbmFtZSk7CisKICAgICAvKiBDb3B5IEZJTEVOQU1FJ3MgZGF0YSB0byBGTiBidXQgcmVt b3ZlIHN0YXJ0aW5nIC86IGlmIGFueS4gICovCi0gICAgcHJlZml4bGVuID0gKChTQ0hBUlMgKGZp bGVuYW1lKSA+IDIKLQkJICAmJiBTUkVGIChmaWxlbmFtZSwgMCkgPT0gJy8nCi0JCSAgJiYgU1JF RiAoZmlsZW5hbWUsIDEpID09ICc6JykKKyAgICBwcmVmaXhsZW4gPSAoKFNDSEFSUyAoZGlybmFt ZXdzbGFzaCkgPiAyCisJCSAgJiYgU1JFRiAoZGlybmFtZXdzbGFzaCwgMCkgPT0gJy8nCisJCSAg JiYgU1JFRiAoZGlybmFtZXdzbGFzaCwgMSkgPT0gJzonKQogCQkgPyAyIDogMCk7Ci0gICAgYmFz ZWxlbiA9IFNCWVRFUyAoZmlsZW5hbWUpIC0gcHJlZml4bGVuOwotICAgIG1lbWNweSAoZm4sIFNE QVRBIChmaWxlbmFtZSkgKyBwcmVmaXhsZW4sIGJhc2VsZW4pOworICAgIGRpcm5hbWVsZW4gPSBT QllURVMgKGRpcm5hbWV3c2xhc2gpIC0gcHJlZml4bGVuOworICAgIG1lbWNweSAoZm4sIFNEQVRB IChkaXJuYW1ld3NsYXNoKSArIHByZWZpeGxlbiwgZGlybmFtZWxlbik7CiAKLSAgICAvKiBMb29w IG92ZXIgc3VmZml4ZXMuICAqLwotICAgIEFVVE9fTElTVDEgKGVtcHR5X3N0cmluZ19vbmx5LCBl bXB0eV91bmlieXRlX3N0cmluZyk7Ci0gICAgdGFpbCA9IE5JTFAgKHN1ZmZpeGVzKSA/IGVtcHR5 X3N0cmluZ19vbmx5IDogc3VmZml4ZXM7CisgICAgLyogTG9vcCBvdmVyIG1pZGRsZWRpcl9hbmRf c3VmZml4ZXMuICAqLworICAgIEFVVE9fTElTVDEgKGVtcHR5X3N0cmluZ19vbmx5LCBGY29ucyAo UW5pbCwgZW1wdHlfdW5pYnl0ZV9zdHJpbmcpKTsKKyAgICB0YWlsID0gTklMUCAobWlkZGxlZGly X2FuZF9zdWZmaXhlcykgPyBlbXB0eV9zdHJpbmdfb25seQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA6IG1pZGRsZWRpcl9hbmRfc3VmZml4ZXM7CiAgICAgRk9SX0VB Q0hfVEFJTF9TQUZFICh0YWlsKQogICAgICAgewotCUxpc3BfT2JqZWN0IHN1ZmZpeCA9IFhDQVIg KHRhaWwpOwotCXB0cmRpZmZfdCBmbmxlbiwgbHN1ZmZpeCA9IFNCWVRFUyAoc3VmZml4KTsKKwlM aXNwX09iamVjdCBtaWRkbGVkaXJfYW5kX3N1ZmZpeCA9IFhDQVIgKHRhaWwpOworICAgICAgICBM aXNwX09iamVjdCBzdWZmaXggPSBYQ0RSIChtaWRkbGVkaXJfYW5kX3N1ZmZpeCk7CiAJTGlzcF9P YmplY3QgaGFuZGxlcjsKIAotCS8qIE1ha2UgY29tcGxldGUgZmlsZW5hbWUgYnkgYXBwZW5kaW5n IFNVRkZJWC4gICovCi0JbWVtY3B5IChmbiArIGJhc2VsZW4sIFNEQVRBIChzdWZmaXgpLCBsc3Vm Zml4ICsgMSk7Ci0JZm5sZW4gPSBiYXNlbGVuICsgbHN1ZmZpeDsKKyAgICAgICAgcHRyZGlmZl90 IGZubGVuID0gb3BlbnBfZmlsbF9maWxlbmFtZV9idWZmZXIgKGZuLCBkaXJuYW1lbGVuLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFzZW5h bWV3ZXh0LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbWlkZGxlZGlyX2FuZF9zdWZmaXgpOwogCiAJLyogQ2hlY2sgdGhhdCB0aGUgZmlsZSBl eGlzdHMgYW5kIGlzIG5vdCBhIGRpcmVjdG9yeS4gICovCiAJLyogV2UgdXNlZCB0byBvbmx5IGNo ZWNrIGZvciBoYW5kbGVycyBvbiBub24tYWJzb2x1dGUgZmlsZSBuYW1lczoKLS0gCjIuMjUuMS53 aW5kb3dzLjEKCg== --00000000000000d42205a6f36a4c-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 31 18:41:56 2020 Received: (at 41242) by debbugs.gnu.org; 31 May 2020 22:41:56 +0000 Received: from localhost ([127.0.0.1]:34049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfWeS-0001jT-2x for submit@debbugs.gnu.org; Sun, 31 May 2020 18:41:56 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:36398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfWeQ-0001jG-Lq for 41242@debbugs.gnu.org; Sun, 31 May 2020 18:41:55 -0400 Received: by mail-ot1-f54.google.com with SMTP id h7so6526856otr.3 for <41242@debbugs.gnu.org>; Sun, 31 May 2020 15:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JrNSJsWFngBmI9pyL5/qLtnu0Z/vKHliSqDUlKb2XTk=; b=aQFky6x6yJctpskLtcvr0OFI1VWNkc0a/NaaxNCrsEO2hEEHHI4EWUlGZXDmU2ww+3 E4xO02lk/j3+gAzR4nRZsCzmw2+g5hov4JQ3GVN+eGb4b6I6IWTA7v9xSvb4zwmAXuf/ QJJS0AEZm4Zql5EijgDnlytypd9p4Lm7ly8IJbIZUBApIItlqprEkqJM8yEB6liDb1lN O0kW5Ci09pug7NwjRgDKap6iKLZUsFSFmV8sHJRGDYbu30ZYxxhKKev6e3j+cxCNUGW2 UnfSWrmmxwljfAZZpEuAS5IwtJTdK8WYwEOgMURtaRbzSmIhC7B9CdjJWSt6D7fkxtWB E3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JrNSJsWFngBmI9pyL5/qLtnu0Z/vKHliSqDUlKb2XTk=; b=QHhH0n/kTszdlWF3csu0U4NdHQhiOAGxUCWGLTDsKw4Co2m+RVRfgIPjmOktnbnxVo XrRJcDDfU4upCfNMdKGMncjhQSEEheizjni0Ne+jXA5j4mG1KLSKiPSQJDEkRwuolThM pMe00NLYGXpdX4+nmW9WYeG1Ir2q3RG+jrKnbGcH5tLr5GJXtyvguBnPrO8FmtzJ65Ls RIT7/hiW9HasJpyn0yaX3bRIPy/fVqR6LyAA+nzPu8lj2/rsqJjuv7oI7qp6xtttoX31 SFIes6JYvQez8pXJOG96cjQQILILgvD+4oz++XrvgwKc4sSubpg2e3DKjPpq8fbCuZzC bPcQ== X-Gm-Message-State: AOAM530Lgmv35cHsLiM/AoxXdAFq+N/Oiz5TllLG5uXHI1twP4ZovSlE Z69yjjIhR1Wo9LJupsVlKAjiAXexqS6Ly1oT8vc= X-Google-Smtp-Source: ABdhPJzTnRhP8uV3z65RgEEkNtFjlOXrXNQYrwLvMsfV6U42hCqLkb/cjQRt6fx9wNVdn2Qh015ctEU+6v4lkmYzbhY= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr14454449oti.202.1590964908918; Sun, 31 May 2020 15:41:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sun, 31 May 2020 19:41:36 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Last night I came up with a fresh idea to properly solve the problem with slow loads. Considering that it happens when `load-path` contains hundreds of directories I thought that a caching mechanism would help. This "cache" would consist of a mapping of files that would get probed when (load "foo") runs. It would be implemented as a hash table. This could get stored in `package-user-dir` and package.el would be in charge of updating it when installing or removing packages, just like autoloads. The contents of this hash table could be something like this: The directory company-20200525.101 could have a file load-cache.el with: company -> ("company-20200525.101/eln-hash/company.eln" "company-20200525.101/company.el" "company-20200525.101/company.elc") [...] The directory helm-20200517.509 could have a file load-cache.el with: helm -> ("helm-20200517.509/eln-hash/helm.eln" "helm-20200517.509/helm.el" "helm-20200517.509/helm.elc") [...] When `load-path` changes we could update the in-memory hash table by loading all the load-cache.el files. Then, when (require 'foo) runs, the loading code could look at the hash table and only fopen() the files associated with the feature we are loading. This would reduce the number of calls to fopen() from thousands to ~3 in the worst case. Of course, this feature would be disabled by default. What do you think? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 03:21:34 2020 Received: (at 41242) by debbugs.gnu.org; 1 Jun 2020 07:21:34 +0000 Received: from localhost ([127.0.0.1]:34385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfelK-0005zd-0O for submit@debbugs.gnu.org; Mon, 01 Jun 2020 03:21:34 -0400 Received: from mx.sdf.org ([205.166.94.20]:65337) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfelI-0005zU-1R for 41242@debbugs.gnu.org; Mon, 01 Jun 2020 03:21:32 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0517LVCF017947 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 1 Jun 2020 07:21:31 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0517LV8g012720; Mon, 1 Jun 2020 07:21:31 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Mon, 01 Jun 2020 07:21:31 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sun, 31 May 2020 19:41:36 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Last night I came up with a fresh idea to properly solve the problem with= slow > loads. Considering that it happens when `load-path` contains hundreds of > directories I thought that a caching mechanism would help. > > This "cache" would consist of a mapping of files that would get probed wh= en > (load "foo") runs. It would be implemented as a hash table. This could get > stored in `package-user-dir` and package.el would be in charge of updatin= g it > when installing or removing packages, just like autoloads. > > The contents of this hash table could be something like this: > > The directory company-20200525.101 could have a file load-cache.el with: > > company -> ("company-20200525.101/eln-hash/company.eln" > "company-20200525.101/company.el" > "company-20200525.101/company.elc") > [...] > > The directory helm-20200517.509 could have a file load-cache.el with: > > helm -> ("helm-20200517.509/eln-hash/helm.eln" > "helm-20200517.509/helm.el" > "helm-20200517.509/helm.elc") > [...] > > When `load-path` changes we could update the in-memory hash table by load= ing all > the load-cache.el files. > > Then, when (require 'foo) runs, the loading code could look at the hash > table and only fopen() the files associated with the feature we are loadi= ng. > This would reduce the number of calls to fopen() from thousands to ~3 in = the > worst case. > > Of course, this feature would be disabled by default. > > What do you think? Hi Nico, could you recall me why this is specific to the native-comp branch? Isn't this a problem that should affect any Emacs on Windows? Thanks Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 09:56:54 2020 Received: (at 41242) by debbugs.gnu.org; 1 Jun 2020 13:56:54 +0000 Received: from localhost ([127.0.0.1]:36674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfkvl-0005m4-EM for submit@debbugs.gnu.org; Mon, 01 Jun 2020 09:56:54 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:34569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfkvj-0005ls-Lc for 41242@debbugs.gnu.org; Mon, 01 Jun 2020 09:56:43 -0400 Received: by mail-ot1-f48.google.com with SMTP id b18so8044403oti.1 for <41242@debbugs.gnu.org>; Mon, 01 Jun 2020 06:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+U+QpU5UlfQHEjBT0fluCCLBlC9+3nwtEFTw49NfZps=; b=GHykdLSgaQFCJ6m+3Sx1NiDWsgN38RwA4IphvWUekXI5/dZuxoHCBvLINgwEtSvJ24 ksrjV/aEf1OSamtBqMOtf9TYbR9YiPp45XMvaBDsHT26FE70aG3zj4cvQ4NxRX/xKLsU cEn9zZOFQFfq1VFEYDRt9OEZoDYTZTPqKA/IyuqNaNkQ52viT0NFMs4OniWuYmFXfXpu gYQOqetXeMU8C3yL/Dqx9TW39hsiYSQZjcy92lG8QBbP7EZ+K8TexYjjNDBjqFfJ2ffA sAMqd99KDcGyMHeVZHc7G81T6H2LLbvbYjwTSQW4uLYiLhW6rDaoyWo0Ws7/AqmaN4ql Ax3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+U+QpU5UlfQHEjBT0fluCCLBlC9+3nwtEFTw49NfZps=; b=N2+xzUcmW2FNjK50qTfXvJlr3420DWhfyigthDGwTPYA4UUcocEaJsab0+mywh9wRN CFcsbRLG86THMgClnlZ4KtJaj+g6SXbvw+BSJV8VfZJzsEpV+IaYMQ+H7Mne301uC02P r6tHpkU7cizT4l02u8kisvumxJWZtOtj2mFX/N1+jtjFU/YD7XFJ3j7l5h5NTkUgXWSF T+r8VzrBvKvNmEb64dry/9iK3XMAkhumQmZi0tCaI1Y2lQVlXMJHxQlZpZ/kJElzibHR SUaS2W9uIEPDCW2kP1KErCwP6Eipuqz/hDu/38n986tVTZ02ZyVuY2IYlu5bpnc/Qgbh 4YfA== X-Gm-Message-State: AOAM530wm7J2mCRzd7meOrhS20WHDCI5IgluTibUgP8wlSJd56LQUX+f sLbN5Ttvqo5jmhL+MinhYZcsYm4/Putqm+VGAqA= X-Google-Smtp-Source: ABdhPJzKXVb3DktDFxo3DU9Ee/8bJqWSWi5R4a5p3C4Ok93EdWtVDg3faWRQWhtJlxSLX5PmFk/C4DnNS8j5Q52iPVI= X-Received: by 2002:a9d:4c19:: with SMTP id l25mr14117511otf.193.1591019797799; Mon, 01 Jun 2020 06:56:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Mon, 1 Jun 2020 10:56:27 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > Isn't this a problem that should affect any Emacs on Windows? You are right. I will open a separate bug. Nico El lun., 1 jun. 2020 a las 4:21, Andrea Corallo () escribi=C3= =B3: > > Nicolas B=C3=A9rtolo writes: > > > Last night I came up with a fresh idea to properly solve the problem wi= th slow > > loads. Considering that it happens when `load-path` contains hundreds o= f > > directories I thought that a caching mechanism would help. > > > > This "cache" would consist of a mapping of files that would get probed = when > > (load "foo") runs. It would be implemented as a hash table. This could = get > > stored in `package-user-dir` and package.el would be in charge of updat= ing it > > when installing or removing packages, just like autoloads. > > > > The contents of this hash table could be something like this: > > > > The directory company-20200525.101 could have a file load-cache.el with= : > > > > company -> ("company-20200525.101/eln-hash/company.eln" > > "company-20200525.101/company.el" > > "company-20200525.101/company.elc") > > [...] > > > > The directory helm-20200517.509 could have a file load-cache.el with: > > > > helm -> ("helm-20200517.509/eln-hash/helm.eln" > > "helm-20200517.509/helm.el" > > "helm-20200517.509/helm.elc") > > [...] > > > > When `load-path` changes we could update the in-memory hash table by lo= ading all > > the load-cache.el files. > > > > Then, when (require 'foo) runs, the loading code could look at the hash > > table and only fopen() the files associated with the feature we are loa= ding. > > This would reduce the number of calls to fopen() from thousands to ~3 i= n the > > worst case. > > > > Of course, this feature would be disabled by default. > > > > What do you think? > > Hi Nico, > > could you recall me why this is specific to the native-comp branch? > Isn't this a problem that should affect any Emacs on Windows? > > Thanks > > Andrea > > -- > akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 15:24:47 2020 Received: (at 41242) by debbugs.gnu.org; 1 Jun 2020 19:24:48 +0000 Received: from localhost ([127.0.0.1]:37036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfq3D-0005QQ-Ky for submit@debbugs.gnu.org; Mon, 01 Jun 2020 15:24:47 -0400 Received: from mx.sdf.org ([205.166.94.20]:53681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfq3B-0005QF-KG for 41242@debbugs.gnu.org; Mon, 01 Jun 2020 15:24:46 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 051JOhFl013858 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 1 Jun 2020 19:24:43 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 051JOh2x003085; Mon, 1 Jun 2020 19:24:43 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Mon, 01 Jun 2020 19:24:43 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sun, 31 May 2020 12:34:16 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi Andrea, > >> I could not compile this patch because non all the calls to openp has >> been updated for the new parameter (my question on adding this stands). > > Sorry. I didn't check the GNU/Linux build. > >> In general please recall to check the stock build when working on >> infrastructure integration, it's quite easy to break. > I have tested that this new patch builds and bootstraps in windows x64, > Ubuntu 18.04 amd64. Both with and without nativecomp. > >> Generally speaking I think the behavior we want to have is that when a >> .eln file is specified this is loaded without re-adding >> Vcomp_native_path_postfix. I could not test it but I suspect this is >> not handled. > > I tested moving company.eln to a directory in load-path without > `comp-native-path-postfix` and then ran (load "company.eln") and it was > loaded from that directory. > > Nico. Hi Nico, thanks this looks better. I've two nits and two hopefully smarter observations: > +++ b/src/lread.c > @@ -1056,31 +1056,25 @@ DEFUN ("get-load-suffixes", Fget_load_suffixes, S= get_load_suffixes, 0, 0, 0, > { > Lisp_Object exts =3D Vload_file_rep_suffixes; > Lisp_Object suffix =3D XCAR (suffixes); > - FOR_EACH_TAIL (exts) > - lst =3D Fcons (concat2 (suffix, XCAR (exts)), lst); > - } > - return Fnreverse (lst); > -} > + bool native_code_suffix =3D (NATIVE_COMP_FLAG > + && strcmp (NATIVE_ELISP_SUFFIX, SSDATA (suffix)) =3D=3D 0); I think with the outer parentesys the second line should go be indented at the level of NATIVE_COMP_FLAG. I'd probably remove the parenthesys and put the newline after the equal. > -static Lisp_Object > -effective_load_path (void) > -{ > -#ifndef HAVE_NATIVE_COMP > - return Vload_path; [...] > +#ifdef HAVE_NATIVE_COMP > + CHECK_STRING_CAR (tail); > + char * suf =3D SSDATA (XCAR (tail)); > + if (strcmp (NATIVE_ELISP_SUFFIX, suf) =3D=3D 0) > + { > + CHECK_STRING (Vcomp_native_path_postfix); > + /* Here we add them in the opposite order so that nreverse > + corrects it. */ > + extended_suf =3D Fcons (Fcons (Qnil, XCAR (tail)), extended_su= f); > + extended_suf =3D Fcons (Fcons (Vcomp_native_path_postfix, XCAR= (tail)), > + extended_suf); > + } > + else > +#endif > + { > + extended_suf =3D Fcons (Fcons (Qnil, XCAR (tail)), extended_su= f); > + } I think GNU style does not want these brackets if the statement is just one. Okay interesting stuffs: In which folders are we going to search if we do (load "...a/path/foo.eln")? I believe in this case we should search the file only in "...a/path/" because the user really want to load this specific file. Am I correct? That said IMO this logic is sufficiently complex to deserve a minimum of testing to make sure we have it under control. Not sure if the best place is files-tests.el or comp-tests.el. Maybe Eli likes to gives his opinion on this last point and on the patch in general. Thanks Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 20:43:08 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 00:43:08 +0000 Received: from localhost ([127.0.0.1]:37346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfv1I-0006bq-1J for submit@debbugs.gnu.org; Mon, 01 Jun 2020 20:43:08 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:38172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfv1H-0006bR-2A for 41242@debbugs.gnu.org; Mon, 01 Jun 2020 20:43:07 -0400 Received: by mail-ot1-f44.google.com with SMTP id o13so9579627otl.5 for <41242@debbugs.gnu.org>; Mon, 01 Jun 2020 17:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0YVXVksGPjFbzO3u5bvKiKb89GNUnh7u6zoHo+6LDYc=; b=WIfyC/7HKWxJWD0lRwCUU9Uq/YBylGNPmBcTw8MrEGjKdgEJcVFg/lghYY3v0NqbSv CJ9Pza+fGzTZpjNS32fe5OpU7SoQ9tE7Mc6YzCian5AGxB2tihjUV/TXTBn21KA6SzNN rLVrLHY/eKcAytnzbpFGRu0fN99kUzFhxnrg3n5WsR0ydEmNI5iL6vJv0EIEtE8v5ZgF QxkVIOVQFNUrJ0wt8DvXSb/q6ftkrkUj+3Vxp58vaheWVywqWooEqvFVA1vGGC7zfg6H W8idrAyEFCR9FtFfoYWybNlkhfPQhUAdLGgzcSgMXyfLFhDdKebLVr1+MaqeOJFMtqnu n84w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0YVXVksGPjFbzO3u5bvKiKb89GNUnh7u6zoHo+6LDYc=; b=Cq9MyMFYW4bV/PhT5SkNIOBlvxlPa4+mT8ixpVy4PNechFgguudiSvhmFp74Gf7L/U dM1rAWxsRMQxgA+NG1xCvY6ZA3o1vSBTh4oZvettn6YQ+tZ2mabgzaFC5zrRDZCAoe0k 7c68r8esLTMOlwlrTXOYK8lwSV6ohCeY5KfD3B8l5qQWNPvAzdrDL9DbaS+ou/Bakxeg 5on4WhhUqACdQhE6nvt8hsvtGqbtQ1A/2JcKsz8UBcdeGyyNyG6rlLCZC3V8b5EMDyke /AB8MsuidgIL/kX5Am7NaM7im3MYBRpW6Icj6M0ePTne0FwKbg26G0Ao4ltjwnXs7lJn cizA== X-Gm-Message-State: AOAM53197X1hcJ61ADCehNM8+WXxycJJH3Gh77ojz+NxRaGojPCQCt7D V1mi0GTmNHKW+2VKetwVXweunBM6iygSDjbXlmQ= X-Google-Smtp-Source: ABdhPJyUTKy6Bz0SH+lHc5OvySdRlBpQhpor5oduQ8dvSIrcN/SWqdzzK6zYjLDSWDDyZgpwdXFALeh7AAcXd+5lFB4= X-Received: by 2002:a9d:5f09:: with SMTP id f9mr18515948oti.202.1591058581297; Mon, 01 Jun 2020 17:43:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Mon, 1 Jun 2020 21:42:50 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) > In which folders are we going to search if we do (load "...a/path/foo.eln")? > I believe in this case we should search the file only in "...a/path/" > because the user really want to load this specific file. Am I correct? I'm not sure we want the load function to be that smart. This is from the manual: ----- The load function is not clever about looking at filename. In the perverse case of a file named foo.el.el, evaluation of (load "foo.el") will indeed find it. ----- I think we should respect that principle when dealing with .eln files, even if it leads to trying to open absurd filenames. I did some tests, and these are the files probed in each case: (load "dir/foo.eln") "{elt}/dir/foo.eln.eln" "{elt}/dir/eln-hash/foo.eln.eln" "{elt}/dir/foo.eln.dll" "{elt}/dir/foo.eln.elc" "{elt}/dir/foo.eln.elc.gz" "{elt}/dir/foo.eln.el" "{elt}/dir/foo.eln.el.gz" "{elt}/dir/foo.eln" "{elt}/dir/foo.eln.gz" where {elt} is an element from `load-path`. (load "C:/dir/foo.eln") "c:/dir/foo.eln.eln" "c:/dir/eln-hash/foo.eln.eln" "c:/dir/foo.eln.dll" "c:/dir/foo.eln.elc" "c:/dir/foo.eln.elc.gz" "c:/dir/foo.eln.el" "c:/dir/foo.eln.el.gz" "c:/dir/foo.eln" "c:/dir/foo.eln.gz" (load "dir/foo.eln" nil nil t) <- nosuffix: t "{elt}/dir/foo.eln" (load "C:/dir/foo.eln" nil nil t) <- nosuffix: t "C:/dir/foo.eln" > That said IMO this logic is sufficiently complex to deserve a minimum of > testing to make sure we have it under control. Not sure if the best > place is files-tests.el or comp-tests.el. I agree about this. I am not sure what is the best way to do it. The list of files probed is inaccessible from Lisp. Thanks, Nico. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 10:43:17 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 14:43:18 +0000 Received: from localhost ([127.0.0.1]:40545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg88L-0007CZ-LA for submit@debbugs.gnu.org; Tue, 02 Jun 2020 10:43:17 -0400 Received: from mx.sdf.org ([205.166.94.20]:56786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg88J-0007CQ-Qj for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 10:43:16 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 052EhEok018534 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 2 Jun 2020 14:43:14 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 052EhE1e020416; Tue, 2 Jun 2020 14:43:14 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Tue, 02 Jun 2020 14:43:14 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Mon, 1 Jun 2020 21:42:50 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: Eli Zaretskii , 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> In which folders are we going to search if we do (load "...a/path/foo.el= n")? > >> I believe in this case we should search the file only in "...a/path/" >> because the user really want to load this specific file. Am I correct? > > I'm not sure we want the load function to be that smart. This is from > the manual: > > ----- > The load function is not clever about looking at filename. In the pervers= e case > of a file named foo.el.el, evaluation of (load "foo.el") will indeed find= it. > ----- > > I think we should respect that principle when dealing with .eln files, ev= en if > it leads to trying to open absurd filenames. Mmmh you are maybe right, but the directory and the filename are two different things, I've to think about it. I'd be curious of other opinions. > I did some tests, and these are the files probed in each case: > > (load "dir/foo.eln") > > "{elt}/dir/foo.eln.eln" > "{elt}/dir/eln-hash/foo.eln.eln" > "{elt}/dir/foo.eln.dll" > "{elt}/dir/foo.eln.elc" > "{elt}/dir/foo.eln.elc.gz" > "{elt}/dir/foo.eln.el" > "{elt}/dir/foo.eln.el.gz" > "{elt}/dir/foo.eln" > "{elt}/dir/foo.eln.gz" > > where {elt} is an element from `load-path`. > > (load "C:/dir/foo.eln") > > "c:/dir/foo.eln.eln" > "c:/dir/eln-hash/foo.eln.eln" > "c:/dir/foo.eln.dll" > "c:/dir/foo.eln.elc" > "c:/dir/foo.eln.elc.gz" > "c:/dir/foo.eln.el" > "c:/dir/foo.eln.el.gz" > "c:/dir/foo.eln" > "c:/dir/foo.eln.gz" > > (load "dir/foo.eln" nil nil t) <- nosuffix: t > > "{elt}/dir/foo.eln" > > (load "C:/dir/foo.eln" nil nil t) <- nosuffix: t > > "C:/dir/foo.eln" > >> That said IMO this logic is sufficiently complex to deserve a minimum of >> testing to make sure we have it under control. Not sure if the best >> place is files-tests.el or comp-tests.el. > > I agree about this. I am not sure what is the best way to do it. The list= of > files probed is inaccessible from Lisp. Yes but we can always compile a file and load it to see what's inside, this is what we do in comp-tests.el, technically is not a problem if we think is necessary. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 11:03:17 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 15:03:17 +0000 Received: from localhost ([127.0.0.1]:40583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg8Rg-0007hn-Oj for submit@debbugs.gnu.org; Tue, 02 Jun 2020 11:03:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg8Ra-0007hW-SP for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 11:03:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46067) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jg8RV-00028R-0a; Tue, 02 Jun 2020 11:03:05 -0400 Received: from [176.228.60.248] (port=3784 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jg8RU-0006Ww-As; Tue, 02 Jun 2020 11:03:04 -0400 Date: Tue, 02 Jun 2020 18:02:47 +0300 Message-Id: <83blm1eciw.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 01 Jun 2020 19:24:43 +0000) Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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 (---) > From: Andrea Corallo > Cc: 41242@debbugs.gnu.org, Eli Zaretskii > Date: Mon, 01 Jun 2020 19:24:43 +0000 > > In which folders are we going to search if we do (load "...a/path/foo.eln")? > > I believe in this case we should search the file only in "...a/path/" > because the user really want to load this specific file. Am I correct? Isn't that already so when we look for *.elc files? > That said IMO this logic is sufficiently complex to deserve a minimum of > testing to make sure we have it under control. Not sure if the best > place is files-tests.el or comp-tests.el. > > Maybe Eli likes to gives his opinion on this last point and on the patch > in general. I think the logic should be consistent with how we search for Lisp files in general. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 12:24:50 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 16:24:50 +0000 Received: from localhost ([127.0.0.1]:40745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg9ib-0001Ry-RA for submit@debbugs.gnu.org; Tue, 02 Jun 2020 12:24:50 -0400 Received: from mx.sdf.org ([205.166.94.20]:52290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jg9iY-0001Rn-I8 for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 12:24:48 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 052GOitD021425 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 2 Jun 2020 16:24:44 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 052GOhbT015715; Tue, 2 Jun 2020 16:24:43 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: <83blm1eciw.fsf@gnu.org> Date: Tue, 02 Jun 2020 16:24:43 +0000 In-Reply-To: <83blm1eciw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Jun 2020 18:02:47 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org 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: >> From: Andrea Corallo >> Cc: 41242@debbugs.gnu.org, Eli Zaretskii >> Date: Mon, 01 Jun 2020 19:24:43 +0000 >> >> In which folders are we going to search if we do (load "...a/path/foo.eln")? >> >> I believe in this case we should search the file only in "...a/path/" >> because the user really want to load this specific file. Am I correct? > > Isn't that already so when we look for *.elc files? Yes but here the hash directory that we use to disambiguate the triplet comes into play so we search there too. This is what Nico posted about what we would probe for a load. (load "C:/dir/foo.eln") "c:/dir/foo.eln.eln" "c:/dir/eln-hash/foo.eln.eln" "c:/dir/foo.eln.dll" "c:/dir/foo.eln.elc" "c:/dir/foo.eln.elc.gz" "c:/dir/foo.eln.el" "c:/dir/foo.eln.el.gz" "c:/dir/foo.eln" "c:/dir/foo.eln.gz" My argument was that in the case of (load "C:/dir/foo.eln") we should try to load only "c:/dir/foo.eln" without having to look into "c:/dir/eln-hash/". But Nico pointed out (probably correctly) that the function is already quite dumb regarding ignoring extentions and is probably not worth doing an exception for this. >> That said IMO this logic is sufficiently complex to deserve a minimum of >> testing to make sure we have it under control. Not sure if the best >> place is files-tests.el or comp-tests.el. >> >> Maybe Eli likes to gives his opinion on this last point and on the patch >> in general. > > I think the logic should be consistent with how we search for Lisp > files in general. > -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 17:17:57 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 21:17:57 +0000 Received: from localhost ([127.0.0.1]:41104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgEIG-0004NJ-W8 for submit@debbugs.gnu.org; Tue, 02 Jun 2020 17:17:57 -0400 Received: from mail-qk1-f170.google.com ([209.85.222.170]:45570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgEIF-0004N6-JD for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 17:17:55 -0400 Received: by mail-qk1-f170.google.com with SMTP id q8so14024381qkm.12 for <41242@debbugs.gnu.org>; Tue, 02 Jun 2020 14:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8TcIN9wXo825y0Cm8p2T39ST6oCKjkeYoxoPU6M6As0=; b=O25iCypH4rhG1VWDye4r45OvdzoZyWP4gmqusZGOLb3cvXFRhOoiXVpOOGxPY2vbRs vT5WzNe5hCxKii1gUT4oTCKHvEa0FPQCO9UTOZwRvQ7fffJZiaVMZt1IsoER1X4FfyWK IDhGNT83pwB7W8Af8NcXMqY/hZdLForRaYbumwBe4nG8lR+wApxNc/4tOyRj8WkiTNMM 9BIkHL009CmW4jSjWc4fR2mc8mGz/7mr2SmcKH6g9ZRhakbsURy7hTjb10XjEFLFU5gD 6B4MoXDHa9ztw44U5GVZMc7R/uMUeqn70o6ODCPEVrNWjOqupXJV/6kp/go9r7/l0kXJ OTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8TcIN9wXo825y0Cm8p2T39ST6oCKjkeYoxoPU6M6As0=; b=C/szc4DiVuxPfMOpxj4bLNd4SetyFvcyCOK0K74Xk3VchOTnW8HZfCO0w7HEIU+dbb /YxOSM6KwLFD2Tyf24rNLJ9sN7yGbkmGUHv/x1nAMyiOESabkHfALKnsTEyBebC9LrAW TW0cDILjVA9eLbK59xBBAucmN8wRu/JjdUf4ukqO630uZVvB/yaV/KDK0rI+MPWVjiqJ sGgJ6OVorOyvtyHno0plIlarQvH+zBpWFJxTzJt+pxZExjwycDfytO1JPxkNiMN96Lh6 QbJq0sV0t4DW3YdG8Z+uMBRxtolEXufyxAkfDt+5StT4y1mKHJTq235RzaXMCE5F7IfV 34tw== X-Gm-Message-State: AOAM530p4IE+lqxjvj5UKbN6BLLGtVw31gdjdqJ9DXrk5l/DJz/FgOdy cihBMu0wXImvJbp9r2tLQ2EltJckHQbfNOvKNFU= X-Google-Smtp-Source: ABdhPJwGqKMhJyOLQ3MdSvtzKNLLy7i/OUbUY2o+R1WoqyBInqgQocBjUQJWvs2fvtCfOx+kgaWvpgWGu7pB6YXnJ4M= X-Received: by 2002:a37:a147:: with SMTP id k68mr26621361qke.62.1591132669910; Tue, 02 Jun 2020 14:17:49 -0700 (PDT) MIME-Version: 1.0 References: <83blm1eciw.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Tue, 2 Jun 2020 18:17:38 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000950b5f05a72071bc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) --000000000000950b5f05a72071bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The recent patches broke the Windows build. There is one patch that fixes it and another one that improves the way to check for the gccjit vers= ion functions. Nico. El mar., 2 jun. 2020 a las 13:24, Andrea Corallo () escribi= =C3=B3: > > Eli Zaretskii writes: > > >> From: Andrea Corallo > >> Cc: 41242@debbugs.gnu.org, Eli Zaretskii > >> Date: Mon, 01 Jun 2020 19:24:43 +0000 > >> > >> In which folders are we going to search if we do (load "...a/path/foo.= eln")? > >> > >> I believe in this case we should search the file only in "...a/path/" > >> because the user really want to load this specific file. Am I correct= ? > > > > Isn't that already so when we look for *.elc files? > > Yes but here the hash directory that we use to disambiguate the triplet > comes into play so we search there too. This is what Nico posted about > what we would probe for a load. > > (load "C:/dir/foo.eln") > > "c:/dir/foo.eln.eln" > "c:/dir/eln-hash/foo.eln.eln" > "c:/dir/foo.eln.dll" > "c:/dir/foo.eln.elc" > "c:/dir/foo.eln.elc.gz" > "c:/dir/foo.eln.el" > "c:/dir/foo.eln.el.gz" > "c:/dir/foo.eln" > "c:/dir/foo.eln.gz" > > My argument was that in the case of (load "C:/dir/foo.eln") we should > try to load only "c:/dir/foo.eln" without having to look into > "c:/dir/eln-hash/". > > But Nico pointed out (probably correctly) that the function is already > quite dumb regarding ignoring extentions and is probably not worth doing > an exception for this. > > >> That said IMO this logic is sufficiently complex to deserve a minimum = of > >> testing to make sure we have it under control. Not sure if the best > >> place is files-tests.el or comp-tests.el. > >> > >> Maybe Eli likes to gives his opinion on this last point and on the pat= ch > >> in general. > > > > I think the logic should be consistent with how we search for Lisp > > files in general. > > > > -- > akrl@sdf.org --000000000000950b5f05a72071bc Content-Type: application/octet-stream; name="0001-Fix-DLL-imports-of-gccjit-version-functions.patch" Content-Disposition: attachment; filename="0001-Fix-DLL-imports-of-gccjit-version-functions.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kayf8ido0 RnJvbSA4MGY2YTdmYzdhNTMxZTE1ZWE5MDlhZjllMjU0NTE1ZTg4ODgwMDVhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAxIEp1biAyMDIwIDE5OjUz OjAwIC0wMzAwClN1YmplY3Q6IFtQQVRDSCAxLzJdIEZpeCBETEwgaW1wb3J0cyBvZiBnY2NqaXQg dmVyc2lvbiBmdW5jdGlvbnMuCgoqIHNyYy9jb21wLmMgKGluaXRfZ2Njaml0X2Z1bmN0aW9ucyk6 IFVzZSBMT0FEX0RMTF9GTl9PUFQgbWFjcm8gdG8KbG9hZCBnY2Nfaml0X3ZlcnNpb25fbWFqb3Is IGdjY19qaXRfdmVyc2lvbl9tYWpvciBhbmQKZ2NjX2ppdF92ZXJzaW9uX3BhdGNobGV2ZWwuCiog c3JjL3czMmNvbW1vbi5oIChMT0FEX0RMTF9GTl9PUFQpOiBBZGQgbWFjcm8gb3B0aW9uYWxseSBs b2FkIGEKZnVuY3Rpb24gZnJvbSBhIERMTC4KLS0tCiBzcmMvY29tcC5jICAgICAgfCAxOCArKysr KysrKysrKystLS0tLS0KIHNyYy93MzJjb21tb24uaCB8ICA4ICsrKysrKysrCiAyIGZpbGVzIGNo YW5nZWQsIDIwIGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3Jj L2NvbXAuYyBiL3NyYy9jb21wLmMKaW5kZXggZDA1NzRhYzVlZjMuLjhlNzU4MmIzZTY1IDEwMDY0 NAotLS0gYS9zcmMvY29tcC5jCisrKyBiL3NyYy9jb21wLmMKQEAgLTk4LDYgKzk4LDkgQEAKICN1 bmRlZiBnY2Nfaml0X3N0cnVjdF9hc190eXBlCiAjdW5kZWYgZ2NjX2ppdF9zdHJ1Y3Rfc2V0X2Zp ZWxkcwogI3VuZGVmIGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlcgorI3VuZGVmIGdjY19qaXRfdmVy c2lvbl9tYWpvcgorI3VuZGVmIGdjY19qaXRfdmVyc2lvbl9taW5vcgorI3VuZGVmIGdjY19qaXRf dmVyc2lvbl9wYXRjaGxldmVsCiAKIC8qIEluIGFscGhhYmV0aWNhbCBvcmRlciAqLwogREVGX0RM TF9GTiAoZ2NjX2ppdF9ydmFsdWUgKiwgZ2NjX2ppdF9jb250ZXh0X25ld19ydmFsdWVfZnJvbV9p bnQsCkBAIC0yMzEsOSArMjM0LDkgQEAgREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9jb250ZXh0 X3NldF9sb2dmaWxlLAogREVGX0RMTF9GTiAodm9pZCwgZ2NjX2ppdF9zdHJ1Y3Rfc2V0X2ZpZWxk cywKICAgICAgICAgICAgIChnY2Nfaml0X3N0cnVjdCAqc3RydWN0X3R5cGUsIGdjY19qaXRfbG9j YXRpb24gKmxvYywgaW50IG51bV9maWVsZHMsCiAgICAgICAgICAgICAgZ2NjX2ppdF9maWVsZCAq KmZpZWxkcykpOwotREVGX0RMTF9GTiAoaW50LCBnY2Nfaml0X3ZlcnNpb25fbWFqb3IpOwotREVG X0RMTF9GTiAoaW50LCBnY2Nfaml0X3ZlcnNpb25fbWlub3IpOwotREVGX0RMTF9GTiAoaW50LCBn Y2Nfaml0X3ZlcnNpb25fcGF0Y2hsZXZlbCk7CitERUZfRExMX0ZOIChpbnQsIGdjY19qaXRfdmVy c2lvbl9tYWpvciwgKHZvaWQpKTsKK0RFRl9ETExfRk4gKGludCwgZ2NjX2ppdF92ZXJzaW9uX21p bm9yLCAodm9pZCkpOworREVGX0RMTF9GTiAoaW50LCBnY2Nfaml0X3ZlcnNpb25fcGF0Y2hsZXZl bCwgKHZvaWQpKTsKIAogc3RhdGljIGJvb2wKIGluaXRfZ2Njaml0X2Z1bmN0aW9ucyAodm9pZCkK QEAgLTI5Nyw5ICszMDAsOSBAQCBpbml0X2djY2ppdF9mdW5jdGlvbnMgKHZvaWQpCiAgIExPQURf RExMX0ZOIChsaWJyYXJ5LCBnY2Nfaml0X3N0cnVjdF9hc190eXBlKTsKICAgTE9BRF9ETExfRk4g KGxpYnJhcnksIGdjY19qaXRfc3RydWN0X3NldF9maWVsZHMpOwogICBMT0FEX0RMTF9GTiAobGli cmFyeSwgZ2NjX2ppdF90eXBlX2dldF9wb2ludGVyKTsKLSAgTE9BRF9ETExfRk4gKGxpYnJhcnks IGdjY19qaXRfdmVyc2lvbl9tYWpvcik7Ci0gIExPQURfRExMX0ZOIChsaWJyYXJ5LCBnY2Nfaml0 X3ZlcnNpb25fbWlub3IpOwotICBMT0FEX0RMTF9GTiAobGlicmFyeSwgZ2NjX2ppdF92ZXJzaW9u X3BhdGNobGV2ZWwpOworICBMT0FEX0RMTF9GTl9PUFQgKGxpYnJhcnksIGdjY19qaXRfdmVyc2lv bl9tYWpvcik7CisgIExPQURfRExMX0ZOX09QVCAobGlicmFyeSwgZ2NjX2ppdF92ZXJzaW9uX21p bm9yKTsKKyAgTE9BRF9ETExfRk5fT1BUIChsaWJyYXJ5LCBnY2Nfaml0X3ZlcnNpb25fcGF0Y2hs ZXZlbCk7CiAKICAgcmV0dXJuIHRydWU7CiB9CkBAIC0zNTgsNiArMzYxLDkgQEAgI2RlZmluZSBn Y2Nfaml0X3J2YWx1ZV9nZXRfdHlwZSBmbl9nY2Nfaml0X3J2YWx1ZV9nZXRfdHlwZQogI2RlZmlu ZSBnY2Nfaml0X3N0cnVjdF9hc190eXBlIGZuX2djY19qaXRfc3RydWN0X2FzX3R5cGUKICNkZWZp bmUgZ2NjX2ppdF9zdHJ1Y3Rfc2V0X2ZpZWxkcyBmbl9nY2Nfaml0X3N0cnVjdF9zZXRfZmllbGRz CiAjZGVmaW5lIGdjY19qaXRfdHlwZV9nZXRfcG9pbnRlciBmbl9nY2Nfaml0X3R5cGVfZ2V0X3Bv aW50ZXIKKyNkZWZpbmUgZ2NjX2ppdF92ZXJzaW9uX21ham9yIGZuX2djY19qaXRfdmVyc2lvbl9t YWpvcgorI2RlZmluZSBnY2Nfaml0X3ZlcnNpb25fbWlub3IgZm5fZ2NjX2ppdF92ZXJzaW9uX21p bm9yCisjZGVmaW5lIGdjY19qaXRfdmVyc2lvbl9wYXRjaGxldmVsIGZuX2djY19qaXRfdmVyc2lv bl9wYXRjaGxldmVsCiAKICNlbmRpZgogCmRpZmYgLS1naXQgYS9zcmMvdzMyY29tbW9uLmggYi9z cmMvdzMyY29tbW9uLmgKaW5kZXggZWI3ZmFhMTkzOWEuLmJkMDFmZDQwNDAxIDEwMDY0NAotLS0g YS9zcmMvdzMyY29tbW9uLmgKKysrIGIvc3JjL3czMmNvbW1vbi5oCkBAIC04MSw2ICs4MSwxNCBA QCAjZGVmaW5lIExPQURfRExMX0ZOKGxpYiwgZnVuYykJCQkJCQlcCiAgICAgfQkJCQkJCQkJCVwK ICAgd2hpbGUgKGZhbHNlKQogCisvKiBMb2FkIGEgZnVuY3Rpb24gZnJvbSB0aGUgRExMLCBhbmQg ZG9uJ3QgZmFpbCBpZiBpdCBkb2VzIG5vdCBleGlzdC4gICovCisjZGVmaW5lIExPQURfRExMX0ZO X09QVChsaWIsIGZ1bmMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg IGRvCQkJCQkJCQkJXAorICAgIHsJCQkJCQkJCQlcCisgICAgICBmbl8jI2Z1bmMgPSAoVzMyX1BG Tl8jI2Z1bmMpIGdldF9wcm9jX2FkZHIgKGxpYiwgI2Z1bmMpOwkJXAorICAgIH0JCQkJCQkJCQlc CisgIHdoaWxlIChmYWxzZSkKKwogI2lmZGVmIEhBVkVfSEFSRkJVWloKIGV4dGVybiBib29sIGhi Zm9udF9pbml0X3czMl9mdW5jcyAoSE1PRFVMRSk7CiAjZW5kaWYKLS0gCjIuMjUuMS53aW5kb3dz LjEKCg== --000000000000950b5f05a72071bc Content-Type: application/octet-stream; name="0002-Remove-kludge-for-detecting-if-gcc_jit_version_major.patch" Content-Disposition: attachment; filename="0002-Remove-kludge-for-detecting-if-gcc_jit_version_major.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kayf8igl1 RnJvbSA4YWE3NjczZjYyNmJmYTJjMTJlNmY5YzhiYmVjMTAyY2UyZmI3MmQxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Tmljb2w9QzM9QTFzPTIwQj1DMz1BOXJ0b2xv Pz0gPG5pY29sYXNiZXJ0b2xvQGdtYWlsLmNvbT4KRGF0ZTogTW9uLCAxIEp1biAyMDIwIDE5OjU2 OjM3IC0wMzAwClN1YmplY3Q6IFtQQVRDSCAyLzJdIFJlbW92ZSBrbHVkZ2UgZm9yIGRldGVjdGlu ZyBpZiBnY2Nfaml0X3ZlcnNpb25fbWFqb3IgY2FuCiBiZSBjYWxsZWQuCgoqIHNyYy9jb21wLmMg KGNvbXAtbGliZ2Njaml0LXZlcnNpb24pOiBVc2UgJ2Rsc3ltJyBpbiBQb3NpeCBhbmQgdGhlCm5v cm1hbCBmdW5jdGlvbiBsb2FkaW5nIG1lY2hhbmlzbSBpbiBXaW5kb3dzLgotLS0KIHNyYy9jb21w LmMgfCAyMyArKysrKysrKysrKysrKy0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE0IGluc2Vy dGlvbnMoKyksIDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2NvbXAuYyBiL3NyYy9j b21wLmMKaW5kZXggOGU3NTgyYjNlNjUuLjA4NGQwYjY3NDViIDEwMDY0NAotLS0gYS9zcmMvY29t cC5jCisrKyBiL3NyYy9jb21wLmMKQEAgLTM2NSw2ICszNjUsOCBAQCAjZGVmaW5lIGdjY19qaXRf dmVyc2lvbl9tYWpvciBmbl9nY2Nfaml0X3ZlcnNpb25fbWFqb3IKICNkZWZpbmUgZ2NjX2ppdF92 ZXJzaW9uX21pbm9yIGZuX2djY19qaXRfdmVyc2lvbl9taW5vcgogI2RlZmluZSBnY2Nfaml0X3Zl cnNpb25fcGF0Y2hsZXZlbCBmbl9nY2Nfaml0X3ZlcnNpb25fcGF0Y2hsZXZlbAogCisjZWxzZQor I2luY2x1ZGUgPGRsZmNuLmg+CiAjZW5kaWYKIAogc3RhdGljIGJvb2wKQEAgLTM5OTksMTUgKzQw MDEsMTggQEAgREVGVU4gKCJjb21wLWxpYmdjY2ppdC12ZXJzaW9uIiwgRmNvbXBfbGliZ2Njaml0 X3ZlcnNpb24sCiAjaWYgZGVmaW5lZCAoTElCR0NDSklUX0hBVkVfZ2NjX2ppdF92ZXJzaW9uKSB8 fCBkZWZpbmVkIChXSU5ET1dTTlQpCiAgIGxvYWRfZ2Njaml0X2lmX25lY2Vzc2FyeSAodHJ1ZSk7 CiAKLSAgLyogRklYTUUgdGhpcyBrbHVkZ2UgaXMgcXVpdGUgYmFkLiAgQ2FuIHdlIGR5bmFtaWNh bGx5IGxvYWQgb24gYWxsCi0gICAgIG9wZXJhdGluZyBzeXN0ZW1zPyAgKi8KLSNwcmFnbWEgR0ND IGRpYWdub3N0aWMgaWdub3JlZCAiLVdhZGRyZXNzIgotICByZXR1cm4gZ2NjX2ppdF92ZXJzaW9u X21ham9yCi0gICAgPyBsaXN0MyAobWFrZV9maXhudW0gKGdjY19qaXRfdmVyc2lvbl9tYWpvciAo KSksCi0JICAgICBtYWtlX2ZpeG51bSAoZ2NjX2ppdF92ZXJzaW9uX21pbm9yICgpKSwKLQkgICAg IG1ha2VfZml4bnVtIChnY2Nfaml0X3ZlcnNpb25fcGF0Y2hsZXZlbCAoKSkpCi0gICAgOiBRbmls OwotI3ByYWdtYSBHQ0MgZGlhZ25vc3RpYyBwb3AKKyAgYm9vbCBva190b19jYWxsOworCisjaWYg ZGVmaW5lZCAoV0lORE9XU05UKQorICBva190b19jYWxsID0gISFmbl9nY2Nfaml0X3ZlcnNpb25f bWFqb3I7CisjZWxzZQorICBva190b19jYWxsID0gISFkbHN5bSAoUlRMRF9ERUZBVUxULCAiZ2Nj X2ppdF92ZXJzaW9uX21ham9yIik7CisjZW5kaWYKKworICByZXR1cm4gb2tfdG9fY2FsbCA/IGxp c3QzIChtYWtlX2ZpeG51bSAoZ2NjX2ppdF92ZXJzaW9uX21ham9yICgpKSwKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbWFrZV9maXhudW0gKGdjY19qaXRfdmVyc2lvbl9taW5vciAoKSks CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1ha2VfZml4bnVtIChnY2Nfaml0X3ZlcnNp b25fcGF0Y2hsZXZlbCAoKSkpCisgICAgICAgICAgICAgICAgICAgIDogUW5pbDsKICNlbHNlCiAg IHJldHVybiBRbmlsOwogI2VuZGlmCi0tIAoyLjI1LjEud2luZG93cy4xCgo= --000000000000950b5f05a72071bc-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 19:08:28 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 23:08:28 +0000 Received: from localhost ([127.0.0.1]:41277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgG18-00079O-HN for submit@debbugs.gnu.org; Tue, 02 Jun 2020 19:08:27 -0400 Received: from mx.sdf.org ([205.166.94.20]:53487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgG16-00079C-EU for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 19:08:21 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 052N8GBe004429 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 2 Jun 2020 23:08:16 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 052N8GpY016810; Tue, 2 Jun 2020 23:08:16 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: <83blm1eciw.fsf@gnu.org> Date: Tue, 02 Jun 2020 23:08:16 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Tue, 2 Jun 2020 18:17:38 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi, > > The recent patches broke the Windows build. There is one patch that > fixes it and another one that improves the way to check for the gccjit ve= rsion > functions. I've pushed "Fix DLL imports of gccjit version functions." on the second I've some perplexity. > Nico. > From 8aa7673f626bfa2c12e6f9c8bbec102ce2fb72d1 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?Nicol=3DC3=3DA1s=3D20B=3DC3=3DA9rtolo?=3D > Date: Mon, 1 Jun 2020 19:56:37 -0300 > Subject: [PATCH 2/2] Remove kludge for detecting if gcc_jit_version_major= can > be called. > > * src/comp.c (comp-libgccjit-version): Use 'dlsym' in Posix and the > normal function loading mechanism in Windows. > --- > src/comp.c | 23 ++++++++++++++--------- > 1 file changed, 14 insertions(+), 9 deletions(-) > > diff --git a/src/comp.c b/src/comp.c > index 8e7582b3e65..084d0b6745b 100644 > --- a/src/comp.c > +++ b/src/comp.c > @@ -365,6 +365,8 @@ #define gcc_jit_version_major fn_gcc_jit_version_major > #define gcc_jit_version_minor fn_gcc_jit_version_minor > #define gcc_jit_version_patchlevel fn_gcc_jit_version_patchlevel >=20=20 > +#else > +#include > #endif >=20=20 > static bool > @@ -3999,15 +4001,18 @@ DEFUN ("comp-libgccjit-version", Fcomp_libgccjit_= version, > #if defined (LIBGCCJIT_HAVE_gcc_jit_version) || defined (WINDOWSNT) > load_gccjit_if_necessary (true); >=20=20 > - /* FIXME this kludge is quite bad. Can we dynamically load on all > - operating systems? */ > -#pragma GCC diagnostic ignored "-Waddress" > - return gcc_jit_version_major > - ? list3 (make_fixnum (gcc_jit_version_major ()), > - make_fixnum (gcc_jit_version_minor ()), > - make_fixnum (gcc_jit_version_patchlevel ())) > - : Qnil; > -#pragma GCC diagnostic pop > + bool ok_to_call; > + > +#if defined (WINDOWSNT) > + ok_to_call =3D !!fn_gcc_jit_version_major; > +#else > + ok_to_call =3D !!dlsym (RTLD_DEFAULT, "gcc_jit_version_major"); > +#endif > + > + return ok_to_call ? list3 (make_fixnum (gcc_jit_version_major ()), > + make_fixnum (gcc_jit_version_minor ()), > + make_fixnum (gcc_jit_version_patchlevel ())) > + : Qnil; > #else > return Qnil; > #endif First given is giving away two pragmas for adding three preprocessor directives I'd say it is adding more kludge then what is removing. Second this code would fail both link time and load time if the linker cannot resolve one of these three functions making the test on the result of dlsym in the run time pointless. To work one needs to go through function pointers as you are doing in Window, but some macrology is requested otherwise would be a kludge^2. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 19:39:26 2020 Received: (at 41242) by debbugs.gnu.org; 2 Jun 2020 23:39:26 +0000 Received: from localhost ([127.0.0.1]:41300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgGVC-0001cE-FO for submit@debbugs.gnu.org; Tue, 02 Jun 2020 19:39:26 -0400 Received: from mail-oi1-f172.google.com ([209.85.167.172]:42292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgGVA-0001bx-DX for 41242@debbugs.gnu.org; Tue, 02 Jun 2020 19:39:24 -0400 Received: by mail-oi1-f172.google.com with SMTP id s21so93291oic.9 for <41242@debbugs.gnu.org>; Tue, 02 Jun 2020 16:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xq7kCRfePUO7i0nupQhyZaNv68GARwEC4NccVXHecN4=; b=YGCbNP8zqIn9dSMQc/hqfJmKgUDzxnArRfhUyEqEjuq5Pk1n5iJyIqL1wJqWoezyVZ VjKGzG7zk5sDM7tn/lZHjp783H3Pt35y4FHeJyHx4XcQVIwnbvrBxpHry1Wa+U9tsNWD Xakm6EDcqagyvlnh/mEQEnL76r5jwJiw9dlCLQ0f8WF0V4eg9DNIa0bjMQj55CmGTAyi 3GqB5Ahowl0tpPdRxYqBm1kGRZIoOXJgXeEz93Y/gzSrtmSyfq0/WW09GnkvfGJPtdsV bkjBpP+HKuusFtr32TnzsGtMDMAxBNX992wYZZW3vysn1CQG+G+RBj5KatInD3yFzlGq T6IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xq7kCRfePUO7i0nupQhyZaNv68GARwEC4NccVXHecN4=; b=q/7xEbE2decfJ3JU1fl1GhupfUhwO2jYPrY0w+3CX8oYA3R7zRhkwDE5PjQDfwVo0G UVUdh2ypXv4339yV1BtPX7O8gTpXls64bvfqxfdyqh7cyBW3ILn24nTcLvZd9aogX2KT FoFG7YJ1haXXqRuPX7yFtn/9WvBfqYKUN//SnhZSgaQVZXBIA970C84SGrlLMRjXc+zG yn3xmBeumjvjJbPMFkFZ6xag9ykvTx7YqaaYYzHLEAiSh1ZLAngk1qfC1iSqpH5d7bb4 12Dx+SQ6EiAXisrL45Eq7mktZqpLaJf/NHJvzzUXlFmm/Zy3m1+VrNvre8LJCMlY2OoO 3zKw== X-Gm-Message-State: AOAM530uNoZCwmSRn+M2+g3oqSN6mFQU/r4vM57+p+WoSLlG5ivYMklj bm6sisK+ZCLoQW09e7mt/zU3Rql3G/mCfcpfYOE= X-Google-Smtp-Source: ABdhPJzBhE17q6YmSOsU2u3uJX51SzxJMuERIE6/EgEbBZwZjXxm3ucXls8b+AQDJiLhZ1ZKX4PiOHmcP9p8vO+HMmE= X-Received: by 2002:aca:e104:: with SMTP id y4mr4309815oig.120.1591141158686; Tue, 02 Jun 2020 16:39:18 -0700 (PDT) MIME-Version: 1.0 References: <83blm1eciw.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Tue, 2 Jun 2020 20:39:06 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > Second this code would fail both link time and load time if the linker > cannot resolve one of these three functions making the test on the > result of dlsym in the run time pointless. I thought that on GNU/Linux the dynamic linker would just resolve a function when necessary (i.e. function call) and not when starting the executable. I assumed that lazy binding was the default, and then the call to dlsym would prevent a crash. This is what the man page of 'ld' says about the '-z lazy' option: When generating an executable or shared library, mark it to tell the dynamic linker to defer function call resolution to the point when the function is called (lazy binding), rather than at load time. Lazy binding is the default. I checked and the call to gcc to link temacs does not include '-z now', so lazy binding should be in effect and the dlsym trick should work. Anyway, if you think that it's ugly I respect that and won't object to it not getting merged. Thanks, Nico. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 03 09:50:41 2020 Received: (at 41242) by debbugs.gnu.org; 3 Jun 2020 13:50:41 +0000 Received: from localhost ([127.0.0.1]:42410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgTmz-00045j-6Q for submit@debbugs.gnu.org; Wed, 03 Jun 2020 09:50:41 -0400 Received: from mx.sdf.org ([205.166.94.20]:50618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgTmx-00045b-GQ for 41242@debbugs.gnu.org; Wed, 03 Jun 2020 09:50:40 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 053DobDi018709 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 3 Jun 2020 13:50:38 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 053Dobfk027428; Wed, 3 Jun 2020 13:50:37 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: <83blm1eciw.fsf@gnu.org> Date: Wed, 03 Jun 2020 13:50:37 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Tue, 2 Jun 2020 20:39:06 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Second this code would fail both link time and load time if the linker >> cannot resolve one of these three functions making the test on the >> result of dlsym in the run time pointless. > > I thought that on GNU/Linux the dynamic linker would just resolve a funct= ion > when necessary (i.e. function call) and not when starting the executable.= I > assumed that lazy binding was the default, and then the call to dlsym wou= ld > prevent a crash. > > This is what the man page of 'ld' says about the '-z lazy' option: > > When generating an executable or shared library, mark it to tell the dyna= mic > linker to defer function call resolution to the point when the function is > called (lazy binding), rather than at load time. Lazy binding is the defa= ult. Yes, but even if you use lazy linking this code would not link if the linker cannot verify the presence of these functions. In this case all users with a non 10 libgccjit. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 03 11:28:49 2020 Received: (at 41242) by debbugs.gnu.org; 3 Jun 2020 15:28:49 +0000 Received: from localhost ([127.0.0.1]:44397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgVJx-0000ci-8z for submit@debbugs.gnu.org; Wed, 03 Jun 2020 11:28:49 -0400 Received: from mail-oi1-f173.google.com ([209.85.167.173]:33708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgVJv-0000cV-Je for 41242@debbugs.gnu.org; Wed, 03 Jun 2020 11:28:47 -0400 Received: by mail-oi1-f173.google.com with SMTP id i74so2174328oib.0 for <41242@debbugs.gnu.org>; Wed, 03 Jun 2020 08:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GcWIsCpZYgLiRAcPak3DDriPzWzciHp4uZUiVQWYFeE=; b=Ne2RzujOxtBzw5ho1EF5CHRTO38gVt4KmHXVaWFm9wB/eXeI/LoCynenKdeZIEaKgg DdCf7pDEaYOCOV4eTzcCja5bktJrnO4yaFN1zWa0mDNmA30eHwJrwYZTReZWxhm3SNe+ x2R0uerY5wr9Avd3xkB2uuYo6yXrSmEtq0kHeXuq0lHqiTGzLl6qHMYRjBZAlfJrqehN 094ZrHTq7qpdgZlUl6ZBR0Z8HaAAxjMZbVOskuq9PGFgq4l9N8D1u8ccHxfAWAog8Psf bEZp8LPpj7Pa7ddp/2cQb7s+rQ5+P+wOktpXctqen2haZGbqM5zus/kYy2WM0kX3KtQT OP5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GcWIsCpZYgLiRAcPak3DDriPzWzciHp4uZUiVQWYFeE=; b=qHR9iTewUtfgE/5hkPexawHy7NKtX0Y8HMKXVFfOzC4B6c6Mz6ZVdt08kKnGSTtd36 JqcEdCuS21+0kk94vsKvunng3TMM2NbBX4CHGmOSUxx2geo6aNNXthEmath3GgTzVhe4 aLRbcG6MfnY6bQ5bfMwfBhBk3YHNomxgLRBaMhSi9U1O3OzctPBK5DmwxDhJ7wOc6kIN tQSlkzdSsPH8stQsO1sEkcJeq0vzl2KwIKG/h/CRJ2AseMlmTpzihWM8vVw3a8JifeK6 hLfeR/L8lmn/tcNqoQH/Fh12BmpRxhXkeDqDKBkuHcqTmOQTbaajqYQ0uU4G2XnN4NHm sx4Q== X-Gm-Message-State: AOAM530900UA08xBV9bhDQgIBAMeHyJEAzjoTBeNlm50A/tP1xVK6Swq mzdf+IPXaputbK9UfJI8bAq52RqIBMc4J7Awgc0= X-Google-Smtp-Source: ABdhPJziv1gOA34TAc6dIGCwMSDQXwdVu+uRno7zpTWK6Y6K79Dd+alO46P6GorD1/pw4dok77s4WjVpP5nO/EhLJos= X-Received: by 2002:aca:e104:: with SMTP id y4mr177132oig.120.1591198116882; Wed, 03 Jun 2020 08:28:36 -0700 (PDT) MIME-Version: 1.0 References: <83blm1eciw.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Wed, 3 Jun 2020 12:28:24 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) > Yes, but even if you use lazy linking this code would not link if the > linker cannot verify the presence of these functions. In this case all > users with a non 10 libgccjit. Shouldn't the first #ifdef remove the code for those users? That one checks for LIBGCCJIT_HAVE_gcc_jit_version. Nico. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 03 12:24:24 2020 Received: (at 41242) by debbugs.gnu.org; 3 Jun 2020 16:24:24 +0000 Received: from localhost ([127.0.0.1]:44478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgWBV-0004AD-Pq for submit@debbugs.gnu.org; Wed, 03 Jun 2020 12:24:24 -0400 Received: from mx.sdf.org ([205.166.94.20]:64776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgWBT-0004A3-Fe for 41242@debbugs.gnu.org; Wed, 03 Jun 2020 12:24:08 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 053GO4Vr013106 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 3 Jun 2020 16:24:04 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 053GO4Gw016170; Wed, 3 Jun 2020 16:24:04 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: <83blm1eciw.fsf@gnu.org> Date: Wed, 03 Jun 2020 16:24:04 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Wed, 3 Jun 2020 12:28:24 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242 Cc: 41242@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Yes, but even if you use lazy linking this code would not link if the >> linker cannot verify the presence of these functions. In this case all >> users with a non 10 libgccjit. > > Shouldn't the first #ifdef remove the code for those users? That one chec= ks for > LIBGCCJIT_HAVE_gcc_jit_version. Oh my, possibly. This code is exactly the definition of what a terrible kludge is. --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 17:41:28 2020 Received: (at 41242-done) by debbugs.gnu.org; 6 Jun 2020 21:41:28 +0000 Received: from localhost ([127.0.0.1]:52619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhgZE-0005cr-Hc for submit@debbugs.gnu.org; Sat, 06 Jun 2020 17:41:28 -0400 Received: from mx.sdf.org ([205.166.94.20]:51034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhgZC-0005cg-Eu for 41242-done@debbugs.gnu.org; Sat, 06 Jun 2020 17:41:27 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 056LfP6U009396 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 6 Jun 2020 21:41:25 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 056LfP58023454; Sat, 6 Jun 2020 21:41:25 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Sat, 06 Jun 2020 21:41:24 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sun, 31 May 2020 12:34:16 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) I did the suggested style modification myself and applied the patch as e38678b268. Thanks I'm closing this. Andrea -- akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 17:52:09 2020 Received: (at 41242-done) by debbugs.gnu.org; 6 Jun 2020 21:52:09 +0000 Received: from localhost ([127.0.0.1]:52655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhgjZ-000839-LY for submit@debbugs.gnu.org; Sat, 06 Jun 2020 17:52:09 -0400 Received: from mail-oi1-f180.google.com ([209.85.167.180]:40444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhgjX-00082v-Ov for 41242-done@debbugs.gnu.org; Sat, 06 Jun 2020 17:52:08 -0400 Received: by mail-oi1-f180.google.com with SMTP id t25so11657320oij.7 for <41242-done@debbugs.gnu.org>; Sat, 06 Jun 2020 14:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7lQ7mxcWEhK8djAExkoY83ACtGjNOa17VYrK3B1Qs/Q=; b=Ra89WWyKFilunHlfMPOLsG9o1MEDEFrzS1auJvrxjNPw9ib/9WHRpvZzexwB6AKnEs pWKxyeAxtuLJ1QBZEcsxApJQVsJ1JXpRsf8+kj5R0MkgEJOw93psKujJagryZ5Ik5f77 NvZ3VvV8ru/Do9lAl6DcVlek2dyOsoTYCoioqWIFpj1lxpJ7Qgn14I5t7b6VU/pe12A5 lNbNKewtGo+BdASlA2wsIXEk+557I+2hlHHj1Is3+3cDff1ZJFnz88HunaVTDbgQHL3U BD3LIZizf4Py6H4jwHq019M9IMsyqNzfaK8uHZJqOMY4GI33qdtjcfy+zjhvFfVXsRiO zM1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7lQ7mxcWEhK8djAExkoY83ACtGjNOa17VYrK3B1Qs/Q=; b=llI+i1sQE7YlmktcCkk/aC0wb46XPRWAUEw+pkJ13BOD8X2OEyJ71cMinWjKhTEAem a9BMy5MTiLswtqq9pzgqCS2S2BqCB1fNx23aWNVNx8F5R74MwVtUPcUFtgOWXeNb/53r QC93SoaIBkT63NPmhcgRB0qEKiL/TtQEn+evOUS3YlJvZJEQQD/bnqmlfUnqYH3d8jMB F6WSQidjcGi+hMZQS2r6e8+GP7zCAi1dg/gIvSCfkTiEq2lmP3bgrcIDyZ10rFDcrCjt /T9FuZNKjzpPTbRG+Yb4KDwVcRWk6Jw2uHwnh0XfZprLHLYbXbPz018enl/AcEB7h1a/ KaWw== X-Gm-Message-State: AOAM533KrMJorWIznfEIcrok+aKJbAUtTDcAXGEAGpIzIFpNv4rqJ0jT ABcrMEegFaSzs0GE4Vi+nCnAjYC6j+I27LdLCwk= X-Google-Smtp-Source: ABdhPJwrvnJVXEGVlYXpAvJJlNuJgrl5xbmrwvZbUD9H75TywOuU1bYwAoEi+cccmT1Tz/hcLiTHrPKVfQL4LpB4y0s= X-Received: by 2002:aca:b742:: with SMTP id h63mr6107404oif.65.1591480322131; Sat, 06 Jun 2020 14:52:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 6 Jun 2020 18:51:49 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) > I did the suggested style modification myself and applied the patch as > e38678b268. Thanks. I didn't have much time during the week to look at how to implement the testing part. I have just came up with an idea that is abusing file-name-handler-alist. If for tests I add a handler that logs all operations we can indirectly access the list of files probed. What do you think of this as a way of testing "load"? Nico. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 18:32:32 2020 Received: (at 41242-done) by debbugs.gnu.org; 6 Jun 2020 22:32:32 +0000 Received: from localhost ([127.0.0.1]:52686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhhMe-0002gz-Hu for submit@debbugs.gnu.org; Sat, 06 Jun 2020 18:32:32 -0400 Received: from mx.sdf.org ([205.166.94.20]:62178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhhMc-0002gp-6V for 41242-done@debbugs.gnu.org; Sat, 06 Jun 2020 18:32:31 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 056MWTKw007819 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 6 Jun 2020 22:32:29 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 056MWTas018703; Sat, 6 Jun 2020 22:32:29 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Sat, 06 Jun 2020 22:32:29 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 6 Jun 2020 18:51:49 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> I did the suggested style modification myself and applied the patch as >> e38678b268. > > Thanks. > > I didn't have much time during the week to look at how to implement the t= esting > part. I have just came up with an idea that is abusing file-name-handler-= alist. > If for tests I add a handler that logs all operations we can indirectly a= ccess > the list of files probed. > > What do you think of this as a way of testing "load"? > > Nico. Hi Nico, mmmh sounds a bit heavy but I'm not able to tell if there is a better and comprehensive at the same time way of testing it. Perhaps if you are chasing the hash bug I guess is more important now. If there's no reasonable way of testing it either we write a couple of ad hoc tests or we say we are fine with that. Not sure if you have seen this https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00050.html there is also the possibility that we are going to change radically all the eln load mechanism. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 18:50:37 2020 Received: (at 41242-done) by debbugs.gnu.org; 6 Jun 2020 22:50:37 +0000 Received: from localhost ([127.0.0.1]:52719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhhe9-00038L-DV for submit@debbugs.gnu.org; Sat, 06 Jun 2020 18:50:37 -0400 Received: from mail-oi1-f174.google.com ([209.85.167.174]:34946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhhe7-000388-Qh for 41242-done@debbugs.gnu.org; Sat, 06 Jun 2020 18:50:36 -0400 Received: by mail-oi1-f174.google.com with SMTP id k4so10191178oik.2 for <41242-done@debbugs.gnu.org>; Sat, 06 Jun 2020 15:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=poVyhO5fN6D7kKbbVzk5dqXCcbECWlt75C9JtIhpJig=; b=rxxaWW0BRgqGWeQQsEF5RhR2cjKISMf2nxkbS2JEzTEQtmksPu7vF/64LmGqFKiBrD ZY4xx0xVB8rfiZ+8Mc4NVZS+f81PCsHOfrhFYySi3vgwsPNH87SQ4s8LGexWommA2J8H QwgtegiBt/c8f6sHzf3fjlJYc5NKh0S+sRb//5jkNkAhR4miAOiakJR3twp4luvsoMUT PCOhXC5W9EZyV3I/sRR8Lnr9Z9XgDLiOO3JODw2pAnQTV/xHDxBuwKWteRxPyuSifA5C UXbkPnb7AoeL9ra3fPLTe/uz58qFpiquLbSaVZSOrWE43kB4g6hT1qa3hGcuJC3NtjJl 6nqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=poVyhO5fN6D7kKbbVzk5dqXCcbECWlt75C9JtIhpJig=; b=ch5JBxoeQ7nmEMNAIstxvPSpzrwrfq30RloEet2oVk/6JxPGNFF7O1XdCguDyLsCPw k8GOVHjg1RtwWbjoCY7XSgrEAI9y2FBM/f3TOpl5lwDnFGO3un/grR4IHAQLEG2VA7fi H+PBt8w8/LKeoWCk3xS39RFxcBBYAp7DUGCBtveddsb5I2W/uOii8CFySbLe4G7q191t y4AKOx04MNtp2gn/eIa5Xp7dNk/o1uhG+L+uUhBkgqM8wbHRYSpWbAItgfGhYuGwBJsS 2ijvBgwaWAWYIb60B0ZbhCz7Pe6+bZZn3C7zFPOx9tNMYi/c8YWBVVNBqcHenn5G51TU GxGg== X-Gm-Message-State: AOAM533vdScCUOI05DpUJbRnS+O1KhCnMu2lNNO7D3cwTmnYgVeIgrFn Bg6PcPnnKHcNgWdHdKVhtJb2suX6fDwpKvrlbOhFtZRakss= X-Google-Smtp-Source: ABdhPJwgtSsnXaZzZbY3TTeS8O9vc2KPeDkHyh2Pv4D6rD/5np9DUG+90Y8/R5U67qVl16a9F5exaUZHFAKpmB3918Y= X-Received: by 2002:aca:58c5:: with SMTP id m188mr6286103oib.175.1591483830098; Sat, 06 Jun 2020 15:50:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Sat, 6 Jun 2020 19:50:17 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) > Perhaps if you are chasing the hash bug I guess is more important now. I agree, but that bug keeps eluding me. I thought of not using a Lisp hashtable and moving to an adhoc C list may be better. > there is also the possibility that we are going to change radically all > the eln load mechanism. No I hadn't. That sounds good. But there are a few issues that I'm not sure about. How would you build the hash? Only the filename? The full path? Both of these options have problems. The current approach makes it easy to avoid filename collisions and to associate .eln files with their source code. Right now I'm trying to fix a bug that prevents the Windows build from dumping. It only happens in 64 bits and nativecomp does not make a difference, but I haven't been able to reproduce it in master. It occurs during the marking stage of the GC. I'll have to bisect the newest changes from master, as I see there has been work on the GC fixing bugs. Nico. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 19:20:08 2020 Received: (at 41242-done) by debbugs.gnu.org; 6 Jun 2020 23:20:08 +0000 Received: from localhost ([127.0.0.1]:52740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhi6i-0003pr-HM for submit@debbugs.gnu.org; Sat, 06 Jun 2020 19:20:08 -0400 Received: from mx.sdf.org ([205.166.94.20]:55601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhi6f-0003pd-N0 for 41242-done@debbugs.gnu.org; Sat, 06 Jun 2020 19:20:07 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 056NK4lm029448 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 6 Jun 2020 23:20:04 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 056NK2k9014061; Sat, 6 Jun 2020 23:20:02 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Sat, 06 Jun 2020 23:20:02 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Sat, 6 Jun 2020 19:50:17 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: >> Perhaps if you are chasing the hash bug I guess is more important now. > > I agree, but that bug keeps eluding me. I thought of not using a Lisp has= htable > and moving to an adhoc C list may be better. > >> there is also the possibility that we are going to change radically all >> the eln load mechanism. > > No I hadn't. That sounds good. But there are a few issues that I'm not su= re > about. How would you build the hash? Only the filename? The full path? Bo= th of > these options have problems. The current approach makes it easy to avoid > filename collisions and to associate .eln files with their source code. Yeah there are a lot of open questions. Certainly if we go for this solution it has to be fully transparent and very robust. Please join the thread there with your observations. > Right now I'm trying to fix a bug that prevents the Windows build from du= mping. > It only happens in 64 bits and nativecomp does not make a difference, but= I > haven't been able to reproduce it in master. It occurs during the marking= stage > of the GC. Mmmh strange, recent GC fixes *should* not impact you. Will be interesting to see what's the issue. > I'll have to bisect the newest changes from master, as I see there has be= en work > on the GC fixing bugs. > > Nico. Andrea --=20 akrl@sdf.org From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 09 10:15:14 2020 Received: (at 41242-done) by debbugs.gnu.org; 9 Jun 2020 14:15:14 +0000 Received: from localhost ([127.0.0.1]:60498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jif22-0001xJ-9a for submit@debbugs.gnu.org; Tue, 09 Jun 2020 10:15:14 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:35288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jif21-0001x6-2I for 41242-done@debbugs.gnu.org; Tue, 09 Jun 2020 10:15:13 -0400 Received: by mail-ot1-f44.google.com with SMTP id 69so16717069otv.2 for <41242-done@debbugs.gnu.org>; Tue, 09 Jun 2020 07:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sux0/R+KL/+Lk988B8OhdYLEvo0iRgbZP+zJz4UXcVs=; b=sJKBG5LdncRihtikkCYfwnXE+XpAaPq5l3kP6PGeuknuVGpZIHSj9ah5sYpVom+FQ1 iIs0ReWl5PK3X+Ul1+9eMYKrbweAo1is3HrrbS49ELI+jJ0ZY3H6xheGw9qHnH/eSx3r ZJn36JcOEnA+/ZJU3s9B0L/fXF1623CFF3CbZNkwK2+rXjaOBTTi3bdHP+flGacanKAt xehLjTBgTfdmtMLLNk3sDapO+5kIpZzMYL3XAD6SPaUPLQQV8O9SbAArZNpBjMpn+Lp3 cucO29m359SwiWaxs5aBYNOembILH6qB5XCV1X0bHgg9YDleOW+qOJBG8vVZ7GLGb1zs Q+WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sux0/R+KL/+Lk988B8OhdYLEvo0iRgbZP+zJz4UXcVs=; b=W5Hd9HhZ5iYsPU9Koxc3goHiG4aVpO8pOiuIkq6RWa6dfbE0e0qWKm+96ShfBMwr2/ IQ4qi7YUP6qi1KfNwE4TScWW5MAzogZQ/L+Ozmg2oPeJTGdS/cFFxN4O9mmrBwvmaBxS TFkscLajcmCJUiPGk5S60YW7IlX32VFhFQv4IYMfSgvsQgdXvhCaqqr4sqd5LD9OFiRI hCU99MnJ3RN5o5ol2RnMifV3MYTW+fZ5pIzU5L3rPtVLX27OMuhIdZkcUJw0jPrAP6oX pWphmZAotLOVKoY4w1SnXXJmeYm6MfT/5+PSdkLSgFGXys/c1jOJrHeJmFQqBEvxPYV/ MdJA== X-Gm-Message-State: AOAM533P7gMXNgBvMBrbI06P809P0XuMvy49pGj8i/iOU87xubTdS7bN zDs8GE+rHFud4aG5CR+j3ix9mh5wF3UGSrH1G9E= X-Google-Smtp-Source: ABdhPJyidTZ4YGiwz1iSKWvr9pZ8X1Fo9UHI6V5zfd2wPrppdYpU2VnLQFecrzBMDd/2JQENXeziWFaC/IeSDzRv7X4= X-Received: by 2002:a9d:4c19:: with SMTP id l25mr20768174otf.193.1591712107258; Tue, 09 Jun 2020 07:15:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Nicolas_B=C3=A9rtolo?= Date: Tue, 9 Jun 2020 11:14:55 -0300 Message-ID: Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000bd08f805a7a75a08" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) --000000000000bd08f805a7a75a08 Content-Type: text/plain; charset="UTF-8" Hi, I have attached a bugfix for the issue that causes crashes when closing Emacs. Ideally I would figure out why iterating over a weak hash-table does not skip elements that were already GC'd, but I could not do it. I feel fixing this bug is very important, so I used a C array to keep the list of native compilation units. --000000000000bd08f805a7a75a08 Content-Type: application/octet-stream; name="0001-Use-a-C-array-to-keep-the-list-of-live-native-compil.patch" Content-Disposition: attachment; filename="0001-Use-a-C-array-to-keep-the-list-of-live-native-compil.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kb809iuj0 RnJvbSA3MTc0Mzc4NTJiN2U5MWE1ZmI5Y2Y4N2RhYjIxYjQ2NjFmM2JiM2I0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIEJlcnRvbG8gPG5pY29sYXNiZXJ0b2xvQGdtYWls LmNvbT4KRGF0ZTogU3VuLCA3IEp1biAyMDIwIDE1OjU0OjUwIC0wMzAwClN1YmplY3Q6IFtQQVRD SF0gVXNlIGEgQyBhcnJheSB0byBrZWVwIHRoZSBsaXN0IG9mIGxpdmUgbmF0aXZlIGNvbXBpbGF0 aW9uCiB1bml0cy4KCkkgd2FzIGdldHRpbmcgY3Jhc2hlcyByZWxhdGVkIHRvIHRoZSBhY2Nlc3Mg dG8gdGhlIGhhc2h0YWJsZSB3aGVuCkVtYWNzIHdhcyBhYm91dCB0byBjbG9zZS4gSSBjb3VsZG4n dCBkZWJ1ZyB0aGVtLCBzbyBJIHJlcGxhY2VkIGl0IHdpdGgKYSBzaW1wbGUgQyBhcnJheS4KCiog c3JjL2xpc3AuaCAoYWxsb2NhdGVfbmF0aXZlX2NvbXBfdW5pdCk6IHJlZ2lzdGVyIGV2ZXJ5IG5h dGl2ZQpjb21waWxhdGlvbiB1bml0IGFsbG9jYXRlZC4KKiBzcmMvY29tcC5oOiBFeHBvc2UgcmVn aXN0ZXJfbmF0aXZlX2NvbXBfdW5pdCAoKSB0byBsaXNwLmguCiogc3JjL2NvbXAuYzogUmVtb3Zl IGFsbF9sb2FkZWRfY29tcF91bml0c19oLiBSZXBsYWNlIGl0IHdpdGggYQpkeW5hbWljYWxseSBz aXplZCBhcnJheS4KLS0tCiBzcmMvY29tcC5jIHwgOTQgKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBzcmMvY29tcC5oIHwgIDUgKysrCiBzcmMv bGlzcC5oIHwgIDkgKysrKy0tCiAzIGZpbGVzIGNoYW5nZWQsIDY2IGluc2VydGlvbnMoKyksIDQy IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29tcC5jCmluZGV4 IDUyMWNhZGNiMTBjLi4xYTdlYWZhYWFkZiAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuYworKysgYi9z cmMvY29tcC5jCkBAIC00MTExLDE3ICs0MTExLDE3IEBAIGhlbHBlcl9QU0VVRE9WRUNUT1JfVFlQ RVBfWFVOVEFHIChMaXNwX09iamVjdCBhLCBlbnVtIHB2ZWNfdHlwZSBjb2RlKQogCiAgIFRoZXJl IGFyZSB0d28gZGF0YSBzdHJ1Y3R1cmVzIHVzZWQ6CiAKLSAgLSBUaGUgYGFsbF9sb2FkZWRfY29t cF91bml0c19oYCBoYXNodGFibGUuCisgIC0gVGhlIGBhbGxfbG9hZGVkX2NvbXBfdW5pdHNgIGxp c3QuCiAKLSAgVGhpcyBoYXNodGFibGUgaXMgdXNlZCBsaWtlIGFuIGFycmF5IG9mIHdlYWsgcmVm ZXJlbmNlcyB0byBuYXRpdmUKLSAgY29tcGlsYXRpb24gdW5pdHMuICBUaGlzIGhhc2ggdGFibGUg aXMgZmlsbGVkIGJ5IGxvYWRfY29tcF91bml0ICgpCi0gIGFuZCBkaXNwb3NlX2FsbF9yZW1haW5p bmdfY29tcF91bml0cyAoKSBpdGVyYXRlcyBvdmVyIGFsbCB2YWx1ZXMKLSAgdGhhdCB3ZXJlIG5v dCBkaXNwb3NlZCBieSB0aGUgR0MgYW5kIHBlcmZvcm1zIGFsbCBkaXNwb3NhbCBzdGVwcwotICB3 aGVuIEVtYWNzIGlzIGNsb3NpbmcuCisgIFRoaXMgbGlzdCBpcyBmaWxsZWQgYnkgYWxsb2NhdGVf bmF0aXZlX2NvbXBfdW5pdCAoKSBhbmQKKyAgZGlzcG9zZV9hbGxfcmVtYWluaW5nX2NvbXBfdW5p dHMgKCkgaXRlcmF0ZXMgb3ZlciBhbGwgdmFsdWVzIHRoYXQKKyAgcmVtYWluIGFuZCBwZXJmb3Jt cyBhbGwgZGlzcG9zYWwgc3RlcHMgd2hlbiBFbWFjcyBpcyBjbG9zaW5nLiAgVGhlCisgIGRpc3Bv c2VfY29tcF91bml0ICgpIGZ1bmN0aW9uIHJlbW92ZXMgZW50cmllcyB0aGF0IHdlcmUgZGlzcG9z ZWQgYnkKKyAgdGhlIEdDLgogCiAgIC0gVGhlIGBkZWxheWVkX2NvbXBfdW5pdF9kaXNwb3NhbF9s aXN0YCBsaXN0LgogCi0gIFRoaXMgaXMgd2VyZSB0aGUgZGlzcG9zZV9jb21wX3VuaXQgKCkgZnVu Y3Rpb24sIHdoZW4gY2FsbGVkIGJ5IHRoZQorICBUaGlzIGlzIHdoZXJlIHRoZSBkaXNwb3NlX2Nv bXBfdW5pdCAoKSBmdW5jdGlvbiwgd2hlbiBjYWxsZWQgYnkgdGhlCiAgIEdDIHN3ZWVwIHN0YWdl LCBzdG9yZXMgdGhlIG9yaWdpbmFsIGZpbGVuYW1lcyBvZiB0aGUgZGlzcG9zZWQgbmF0aXZlCiAg IGNvbXBpbGF0aW9uIHVuaXRzLiAgVGhpcyBpcyBhbiBhZC1ob2MgQyBzdHJ1Y3R1cmUgaW5zdGVh ZCBvZiBhIExpc3AKICAgY29ucyBiZWNhdXNlIHdlIG5lZWQgdG8gYWxsb2NhdGUgaW5zdGFuY2Vz IG9mIHRoaXMgc3RydWN0dXJlIGR1cmluZwpAQCAtNDEzNiw3ICs0MTM2LDM1IEBAIGhlbHBlcl9Q U0VVRE9WRUNUT1JfVFlQRVBfWFVOVEFHIChMaXNwX09iamVjdCBhLCBlbnVtIHB2ZWNfdHlwZSBj b2RlKQogI2lmZGVmIFdJTkRPV1NOVAogI2RlZmluZSBPTERfRUxOX1NVRkZJWF9SRUdFWFAgYnVp bGRfc3RyaW5nICgiXFwuZWxuXFwub2xkXFwnIikKIAotc3RhdGljIExpc3BfT2JqZWN0IGFsbF9s b2FkZWRfY29tcF91bml0c19oOworc3RydWN0IGFsbF9sb2FkZWRfY29tcF91bml0c19zIHsKKyAg c3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqKm1lbTsKKyAgc2l6ZV90IHNpemU7CisgIHNp emVfdCBjYXBhY2l0eTsKK307CisKK3N0YXRpYyBzdHJ1Y3QgYWxsX2xvYWRlZF9jb21wX3VuaXRz X3MgYWxsX2xvYWRlZF9jb21wX3VuaXRzOworCitzdGF0aWMgdm9pZAorbG9hZGVkX2NvbXBfdW5p dHNfcmVtb3ZlIChzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICogY29tcF91KQoreworICBz aXplX3QgaTsKKyAgYm9vbCBmb3VuZCA9IGZhbHNlOworICBmb3IgKGkgPSAwIDsgaSA8IGFsbF9s b2FkZWRfY29tcF91bml0cy5zaXplOyArK2kpCisgICAgaWYgKGFsbF9sb2FkZWRfY29tcF91bml0 cy5tZW1baV0gPT0gY29tcF91KQorICAgICAgeworICAgICAgICBmb3VuZCA9IHRydWU7CisgICAg ICAgIGJyZWFrOworICAgICAgfQorICBpZiAoIWZvdW5kKQorICAgIGVtYWNzX2Fib3J0ICgpOwor CisgIHNpemVfdCBlbGVtZW50c19vbl9yaWdodCA9IGFsbF9sb2FkZWRfY29tcF91bml0cy5zaXpl IC0gaSAtIDE7CisgIG1lbW1vdmUgKCZhbGxfbG9hZGVkX2NvbXBfdW5pdHMubWVtW2ldLAorICAg ICAgICAgICAmYWxsX2xvYWRlZF9jb21wX3VuaXRzLm1lbVtpICsgMV0sCisgICAgICAgICAgIGVs ZW1lbnRzX29uX3JpZ2h0ICogc2l6ZW9mIChzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICop KTsKKworICBhbGxfbG9hZGVkX2NvbXBfdW5pdHMubWVtWy0tYWxsX2xvYWRlZF9jb21wX3VuaXRz LnNpemVdID0gTlVMTDsKK30KIAogLyogV2UgbmVlZCB0byBhbGxvY2F0ZSBpbnN0YW5jZXMgb2Yg dGhpcyBzdHJ1Y3QgZHVyaW5nIGEgR0Mgc3dlZXAuCiAgICBUaGlzIGlzIHdoeSBpdCBjYW4ndCBi ZSB0cmFuc2Zvcm1lZCBpbnRvIGEgc2ltcGxlIGNvbnMuICAqLwpAQCAtNDE5MywxNyArNDIyMSw5 IEBAIGNsZWFuX3BhY2thZ2VfdXNlcl9kaXJfb2Zfb2xkX2NvbXBfdW5pdHMgKHZvaWQpCiB2b2lk CiBkaXNwb3NlX2FsbF9yZW1haW5pbmdfY29tcF91bml0cyAodm9pZCkKIHsKLSAgc3RydWN0IExp c3BfSGFzaF9UYWJsZSAqaCA9IFhIQVNIX1RBQkxFIChhbGxfbG9hZGVkX2NvbXBfdW5pdHNfaCk7 Ci0KLSAgZm9yIChwdHJkaWZmX3QgaSA9IDA7IGkgPCBIQVNIX1RBQkxFX1NJWkUgKGgpOyArK2kp CisgIGZvciAocHRyZGlmZl90IGkgPSBhbGxfbG9hZGVkX2NvbXBfdW5pdHMuc2l6ZSAtIDE7IGkg Pj0gMDsgLS1pKQogICAgIHsKLSAgICAgIExpc3BfT2JqZWN0IGsgPSBIQVNIX0tFWSAoaCwgaSk7 Ci0gICAgICBpZiAoIUVRIChrLCBRdW5ib3VuZCkpCi0gICAgICAgIHsKLSAgICAgICAgICBMaXNw X09iamVjdCB2YWwgPSBIQVNIX1ZBTFVFIChoLCBpKTsKLSAgICAgICAgICBzdHJ1Y3QgTGlzcF9O YXRpdmVfQ29tcF9Vbml0ICpjdSA9IFhOQVRJVkVfQ09NUF9VTklUICh2YWwpOwotICAgICAgICAg IGRpc3Bvc2VfY29tcF91bml0IChjdSwgZmFsc2UpOwotICAgICAgICB9CisgICAgICBkaXNwb3Nl X2NvbXBfdW5pdCAoYWxsX2xvYWRlZF9jb21wX3VuaXRzLm1lbVtpXSwgZmFsc2UpOwogICAgIH0K IH0KIApAQCAtNDIyNywyMiArNDI0NywyNiBAQCBmaW5pc2hfZGVsYXllZF9kaXNwb3NhbF9vZl9j b21wX3VuaXRzICh2b2lkKQogICAgICAgeGZyZWUgKGl0ZW0pOwogICAgIH0KIH0KLSNlbmRpZgog CiAvKiBUaGlzIGZ1bmN0aW9uIHB1dHMgdGhlIGNvbXBpbGF0aW9uIHVuaXQgaW4gdGhlCi0gIGBh bGxfbG9hZGVkX2NvbXBfdW5pdHNfaGAgaGFzaG1hcC4gICovCi1zdGF0aWMgdm9pZAotcmVnaXN0 ZXJfbmF0aXZlX2NvbXBfdW5pdCAoTGlzcF9PYmplY3QgY29tcF91KQorICBgYWxsX2xvYWRlZF9j b21wX3VuaXRzYCBsaXN0LiAgKi8KK3ZvaWQKK3JlZ2lzdGVyX25hdGl2ZV9jb21wX3VuaXQgKHN0 cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKiBjb21wX3UpCiB7Ci0jaWZkZWYgV0lORE9XU05U Ci0gIC8qIFdlIGhhdmUgdG8gZG8gdGhpcyBzaW5jZSB3ZSBjYW4ndCB1c2UgYGdlbnN5bScuIFRo aXMgZnVuY3Rpb24gaXMKLSAgICAgY2FsbGVkIGVhcmx5IHdoZW4gbG9hZGluZyBhIGR1bXAgZmls ZSBhbmQgc3Vici5lbCBtYXkgbm90IGhhdmUKLSAgICAgYmVlbiBsb2FkZWQgeWV0LiAgKi8KLSAg c3RhdGljIGludG1heF90IGNvdW50OworICAvKiAgR3JvdyB0aGUgYXJyYXkgaWYgbmVjZXNzYXJ5 LiAgKi8KKyAgaWYgKGFsbF9sb2FkZWRfY29tcF91bml0cy5zaXplICsgMSA+IGFsbF9sb2FkZWRf Y29tcF91bml0cy5jYXBhY2l0eSkKKyAgICB7CisgICAgICBhbGxfbG9hZGVkX2NvbXBfdW5pdHMu Y2FwYWNpdHkgPSBtYXggKDEsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDIgKiBhbGxfbG9hZGVkX2NvbXBfdW5pdHMuY2FwYWNpdHkpOworICAgICAgYWxsX2xv YWRlZF9jb21wX3VuaXRzLm1lbQorICAgICAgICA9IHhyZWFsbG9jIChhbGxfbG9hZGVkX2NvbXBf dW5pdHMubWVtLAorICAgICAgICAgICAgICAgICAgICBhbGxfbG9hZGVkX2NvbXBfdW5pdHMuY2Fw YWNpdHkKKyAgICAgICAgICAgICAgICAgICAgKiBzaXplb2YgKHN0cnVjdCBMaXNwX05hdGl2ZV9D b21wX1VuaXQgKikpOworICAgIH0KIAotICBGcHV0aGFzaCAobWFrZV9pbnQgKGNvdW50KyspLCBj b21wX3UsIGFsbF9sb2FkZWRfY29tcF91bml0c19oKTsKLSNlbmRpZgorICBhbGxfbG9hZGVkX2Nv bXBfdW5pdHMubWVtW2FsbF9sb2FkZWRfY29tcF91bml0cy5zaXplKytdID0gY29tcF91OwogfQor I2VuZGlmCiAKIC8qIFRoaXMgZnVuY3Rpb24gZGlzcG9zZXMgY29tcGlsYXRpb24gdW5pdHMuICBJ dCBpcyBjYWxsZWQgZHVyaW5nIHRoZSBHQyBzd2VlcAogICAgc3RhZ2UgYW5kIHdoZW4gRW1hY3Mg aXMgY2xvc2luZy4KQEAgLTQyNTcsNiArNDI4MSw3IEBAIGRpc3Bvc2VfY29tcF91bml0IChzdHJ1 Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0ICpjb21wX2hhbmRsZSwgYm9vbCBkZWxheSkKICAgZWFz c2VydCAoY29tcF9oYW5kbGUtPmhhbmRsZSk7CiAgIGR5bmxpYl9jbG9zZSAoY29tcF9oYW5kbGUt PmhhbmRsZSk7CiAjaWZkZWYgV0lORE9XU05UCisgIGxvYWRlZF9jb21wX3VuaXRzX3JlbW92ZSAo Y29tcF9oYW5kbGUpOwogICBpZiAoIWRlbGF5KQogICAgIHsKICAgICAgIExpc3BfT2JqZWN0IGRp cm5hbWUgPSBpbnRlcm5hbF9jb25kaXRpb25fY2FzZV8xICgKQEAgLTQ1MDEsMTIgKzQ1MjYsNiBA QCBsb2FkX2NvbXBfdW5pdCAoc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqY29tcF91LCBi b29sIGxvYWRpbmdfZHVtcCwKICAgICAgIGRfdmVjX2xlbiA9IFhGSVhOVU0gKEZsZW5ndGggKGNv bXBfdS0+ZGF0YV9pbXB1cmVfdmVjKSk7CiAgICAgICBmb3IgKEVNQUNTX0lOVCBpID0gMDsgaSA8 IGRfdmVjX2xlbjsgaSsrKQogCWRhdGFfaW1wX3JlbG9jc1tpXSA9IEFSRUYgKGNvbXBfdS0+ZGF0 YV9pbXB1cmVfdmVjLCBpKTsKLQotICAgICAgLyogSWYgd2UgcmVnaXN0ZXIgdGhlbSB3aGlsZSBk dW1waW5nIHdlIHdpbGwgZ2V0IHNvbWUgZW50cmllcyBpbgotCSB0aGUgaGFzaCB0YWJsZSB0aGF0 IHdpbGwgYmUgZHVwbGljYXRlZCB3aGVuIHBkdW1wZXIgY2FsbHMKLQkgbG9hZF9jb21wX3VuaXQu ICAqLwotICAgICAgaWYgKCF3aWxsX2R1bXBfcCAoKSkKLQlyZWdpc3Rlcl9uYXRpdmVfY29tcF91 bml0IChjb21wX3VfbGlzcF9vYmopOwogICAgIH0KIAogICBpZiAoIWxvYWRpbmdfZHVtcCkKQEAg LTQ4MTgsMTEgKzQ4MzcsNiBAQCBzeW1zX29mX2NvbXAgKHZvaWQpCiAgIHN0YXRpY3BybyAoJmRl bGF5ZWRfc291cmNlcyk7CiAgIGRlbGF5ZWRfc291cmNlcyA9IFFuaWw7CiAKLSNpZmRlZiBXSU5E T1dTTlQKLSAgc3RhdGljcHJvICgmYWxsX2xvYWRlZF9jb21wX3VuaXRzX2gpOwotICBhbGxfbG9h ZGVkX2NvbXBfdW5pdHNfaCA9IENBTExOIChGbWFrZV9oYXNoX3RhYmxlLCBRQ3dlYWtuZXNzLCBR dmFsdWUpOwotI2VuZGlmCi0KICAgREVGVkFSX0xJU1AgKCJjb21wLWN0eHQiLCBWY29tcF9jdHh0 LAogCSAgICAgICBkb2M6IC8qIFRoZSBjb21waWxlciBjb250ZXh0LiAgKi8pOwogICBWY29tcF9j dHh0ID0gUW5pbDsKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmggYi9zcmMvY29tcC5oCmluZGV4IDUw NzM3OWJmNWU2Li5lNDE5NmQ0YTVmOSAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuaAorKysgYi9zcmMv Y29tcC5oCkBAIC0xMDEsNiArMTAxLDExIEBAIFhOQVRJVkVfQ09NUF9VTklUIChMaXNwX09iamVj dCBhKQogCiBleHRlcm4gdm9pZCBjbGVhbl9wYWNrYWdlX3VzZXJfZGlyX29mX29sZF9jb21wX3Vu aXRzICh2b2lkKTsKIAorI2lmZGVmIFdJTkRPV1NOVAorZXh0ZXJuIHZvaWQKK3JlZ2lzdGVyX25h dGl2ZV9jb21wX3VuaXQgKHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKiBjb21wX3VuaXQp OworI2VuZGlmCisKICNlbHNlIC8qICNpZmRlZiBIQVZFX05BVElWRV9DT01QICovCiAKIHN0YXRp YyBpbmxpbmUgdm9pZApkaWZmIC0tZ2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNwLmgKaW5kZXgg MjJjZDE2NmM5NTQuLmY2NDQ2M2FmZWVjIDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3Ny Yy9saXNwLmgKQEAgLTQ3NjQsOCArNDc2NCwxMyBAQCBTVUJSX05BVElWRV9DT01QSUxFRFAgKExp c3BfT2JqZWN0IGEpCiBJTkxJTkUgc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqCiBhbGxv Y2F0ZV9uYXRpdmVfY29tcF91bml0ICh2b2lkKQogewotICByZXR1cm4gQUxMT0NBVEVfWkVST0VE X1BTRVVET1ZFQ1RPUiAoc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5pdCwKLQkJCQkgICAgICAg ZGF0YV9pbXB1cmVfdmVjLCBQVkVDX05BVElWRV9DT01QX1VOSVQpOworICBzdHJ1Y3QgTGlzcF9O YXRpdmVfQ29tcF9Vbml0ICogY29tcF91CisgICAgPSBBTExPQ0FURV9aRVJPRURfUFNFVURPVkVD VE9SIChzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0LAorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGF0YV9pbXB1cmVfdmVjLCBQVkVDX05BVElWRV9DT01QX1VOSVQpOwor I2lmZGVmIFdJTkRPV1NOVAorICByZWdpc3Rlcl9uYXRpdmVfY29tcF91bml0IChjb21wX3UpOwor I2VuZGlmCisgIHJldHVybiBjb21wX3U7CiB9CiAjZWxzZQogSU5MSU5FIGJvb2wKLS0gCjIuMjUu MS53aW5kb3dzLjEKCg== --000000000000bd08f805a7a75a08-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 09 13:17:22 2020 Received: (at 41242-done) by debbugs.gnu.org; 9 Jun 2020 17:17:23 +0000 Received: from localhost ([127.0.0.1]:60848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jihsI-0006hR-Mz for submit@debbugs.gnu.org; Tue, 09 Jun 2020 13:17:22 -0400 Received: from mx.sdf.org ([205.166.94.20]:55618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jihsG-0006hJ-L2 for 41242-done@debbugs.gnu.org; Tue, 09 Jun 2020 13:17:21 -0400 Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 059HHJwR028284 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 9 Jun 2020 17:17:19 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 059HHJZH012821; Tue, 9 Jun 2020 17:17:19 GMT From: Andrea Corallo To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. References: Date: Tue, 09 Jun 2020 17:17:19 +0000 In-Reply-To: ("Nicolas =?utf-8?Q?B=C3=A9rtolo=22's?= message of "Tue, 9 Jun 2020 11:14:55 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41242-done Cc: 41242-done@debbugs.gnu.org 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 (-) Nicolas B=C3=A9rtolo writes: > Hi, > > I have attached a bugfix for the issue that causes crashes when closing E= macs. > > Ideally I would figure out why iterating over a weak hash-table does not= skip > elements that were already GC'd, but I could not do it. I feel fixing > this bug is > very important, so I used a C array to keep the list of native > compilation units. Hi Nico, at a quick look your code to itereate looks correct and very similar to other we have in the codebase so this is important to understand what is going on. Have you tried to run a reproducer like the following? =3D=3D=3D=3D=3D=3D ;;; -*- lexical-binding: t; -*- (setq gc-cons-threshold most-positive-fixnum) (defun foo ()) (load (native-compile #'foo)) (setq xxx (make-hash-table :weakness 'value)) (puthash 1 (subr-native-comp-unit (symbol-function #'foo)) xxx) (defun foo ()) (maphash (lambda (k v) (message "%s %s" k v)) xxx) (garbage-collect) (maphash (lambda (k v) (message "%s %s" k v)) xxx) =3D=3D=3D=3D=3D=3D The thing is that 'mark_and_sweep_weak_table_contents' is called after convetional mark and before conventional sweep. This will eventually call 'sweep_weak_table' that sets the Qunbound as key. Should be relativelly easy to see that the CU is sweeped there, and in case is not see the reason. A possibility where I bet is that something goes wrong dumping and reviving a weak hashtable (like this is not in 'weak_hash_tables'). You can quickly check against that moving the creation of your hash such that is created at each startup. Hope it helps Andrea --=20 akrl@sdf.org From unknown Mon Aug 18 14:24:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 08 Jul 2020 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator