#33848 - Store references in SBCL-compiled code are "invisible"

Package	Source(s)		Maintainer(s)
guix		PTS Buildd Popcon

Message #151 received at 33848@debbugs.gnu.org (full text, mbox, reply):

Received: (at 33848) by debbugs.gnu.org; 5 Apr 2021 23:06:39 +0000
From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 05 19:06:38 2021
Received: from localhost ([127.0.0.1]:38862 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1lTYIo-0002Ce-Mk
	for submit@debbugs.gnu.org; Mon, 05 Apr 2021 19:06:38 -0400
Received: from world.peace.net ([64.112.178.59]:44152)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@netris.org>) id 1lTYIm-0002CP-MV
 for 33848@debbugs.gnu.org; Mon, 05 Apr 2021 19:06:37 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@netris.org>)
 id 1lTYIg-0005vv-9X; Mon, 05 Apr 2021 19:06:30 -0400
From: Mark H Weaver <mhw@netris.org>
To: Ludovic Courtès <ludo@gnu.org>
Subject: Re: bug#33848: Store references in SBCL-compiled code are "invisible"
In-Reply-To: <87ft04sefs.fsf@gnu.org>
References: <87r2e8jpfx.fsf@gnu.org> <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>
 <871rbtc3j5.fsf@netris.org> <87r1js9udv.fsf@netris.org>
 <87sg47vp16.fsf@ambrevar.xyz> <875z139liy.fsf@netris.org>
 <87ft04sefs.fsf@gnu.org>
Date: Mon, 05 Apr 2021 19:04:44 -0400
Message-ID: <8735w472oo.fsf@netris.org>
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: 33848
Cc: Guillaume Le Vaillant <glv@posteo.net>,
 Pierre Neidhardt <mail@ambrevar.xyz>, 33848@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> With this patch applied, all graft derivations will be rebuilt, but
>> *only* grafts.  When it's ready (i.e. when it has better comments,
>> docstrings, etc), this change is perfectly appropriate for 'master'.
>
> The GC’s scanner still gets it wrong though.  I wonder whether having
> the grafting code more capable than the scanner could lead to bad
> surprises.  WDYT?

I've thought about it, and I've been unable to think of any
disadvantage to making the grafter more capable than the scanner.
It seems to me a pure win.

That the scanner fails to find all references is clearly an important
problem that should be fixed ASAP, but as far as I can tell, improving
the grafter would not make that problem any worse or create any new
problems.

Improving the grafter should have the following effects:

(1) Reducing the number of cases where ungrafted code with security
    flaws is being used on our systems.

(2) Fixing problems in our Fish, Nyxt, and Common Lisp packages.

Improving the scanner, or adding phases to selected packages or build
systems to copy hidden references to an ASCII file, should have the
following effects:

(1) Reducing the number of cases where run-time dependencies are not
    known to Guix, which could lead to dependencies being prematurely
    GC'd or excluded from things like "guix pack".

So, it seems to me that we should persue both of these improvements
concurrently, and I see no practical advantage to postponing one for the
sake of rolling them both out at the same time.  Of course, I welcome
other opinions on this.

What do you think?

     Thanks,
       Mark

Display info messages

Send a report that this bug log contains spam.

debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Sat Apr 12 13:12:11 2025; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

#33848 Store references in SBCL-compiled code are "invisible"