From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 11:24:51 2021 Received: (at 33848) by debbugs.gnu.org; 1 Apr 2021 15:24:51 +0000 Received: from localhost ([127.0.0.1]:58310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRzBj-0003Bl-AZ for submit@debbugs.gnu.org; Thu, 01 Apr 2021 11:24:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRzBh-0003BZ-L4 for 33848@debbugs.gnu.org; Thu, 01 Apr 2021 11:24:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56521) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRzBY-0007Wc-PU; Thu, 01 Apr 2021 11:24:40 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=57130 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRzBY-0007ql-7N; Thu, 01 Apr 2021 11:24:40 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Pierre Neidhardt Subject: Re: bug#33848: Store references in SBCL-compiled code are "invisible" References: <87r2e8jpfx.fsf@gnu.org> <877efwe04u.fsf@gnu.org> <8736qji7c1.fsf@ambrevar.xyz> <87tvizvzgk.fsf@netris.org> <87o9979gfn.fsf@gnu.org> <87tvizgghs.fsf@ambrevar.xyz> <87k1juaomo.fsf@gnu.org> <87muoqhk62.fsf@ambrevar.xyz> <87zhsq8wkj.fsf@gnu.org> <87d0pmhbgn.fsf@ambrevar.xyz> <87r2e28tkv.fsf@gnu.org> <874laygkiy.fsf@ambrevar.xyz> <87lfa5eymf.fsf@ambrevar.xyz> <87tuoscsk9.fsf@gnu.org> <87im57b8u7.fsf@ambrevar.xyz> <87czvebky2.fsf@netris.org> <87eefu30a4.fsf@gnu.org> <87im56l6es.fsf@yamatai> <87wntm8j18.fsf@ambrevar.xyz> <87a6qil4b1.fsf@yamatai> <87a6qiz5b3.fsf@ambrevar.xyz> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 12 Germinal an 229 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 01 Apr 2021 17:24:37 +0200 In-Reply-To: <87a6qiz5b3.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Thu, 01 Apr 2021 12:07:28 +0200") Message-ID: <87pmze58p6.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Pierre Neidhardt skribis: > I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) > might be able to fix this much quicker than me! :) There’s ‘%graft-hooks’ in (guix build graft). One could add a hook that would do nothing except for SBCL packages; for SBCL packages, it would to the UCS-4 rewriting “somehow”. Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ambrevar.xyz (xyz)] -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.92 listed in list.dnswl.org] X-Debbugs-Envelope-To: 33848 Cc: Guillaume Le Vaillant , Mark H Weaver , 33848@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: 0.3 (/) Pierre Neidhardt skribis: > I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) > might be able to fix this much quicker than me! :) There=E2=80=99s =E2=80=98%graft-hooks=E2=80=99 in (guix build graft). One = could add a hook that would do nothing except for SBCL packages; for SBCL packages, it would to the UCS-4 rewriting =E2=80=9Csomehow=E2=80=9D. The other option, which might be easier, would be to arrange to not use UCS-4 in the first place, by choosing a bytevector data type for string literals known to contain a store reference. It can be done if we know where those references come from=E2=80=94e.g., they=E2=80=99re introduced by =E2=80=98substitute*=E2=80=99 on the source. I hope this makes sense! Ludo=E2=80=99.