From owner-freebsd-current@freebsd.org Mon Dec 3 19:18:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84CB113301E0 for ; Mon, 3 Dec 2018 19:18:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67C8C69B65 for ; Mon, 3 Dec 2018 19:18:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id e5so15113589qtr.12 for ; Mon, 03 Dec 2018 11:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4uP8tM2rLUUa1UTW9Oahi30oxW8d9hGTydha3H13uOc=; b=WbfGEHTvZSmst8MUUU1zPH4szVJdBacBwPc03OJPFTIT8Cj+xNBhbFFflsrP71GkHw Gy2LR6ozsXM5ESbpS1JX0cGOaTVW8Dg/XW9HlEjysHYYaVaKAsmW9nMlsaV4v602jcak Ei867qTy9siwIGuz5YI0gSm2gQQbzvuJyTbZYZXlaF3St2CVci1zPZOqcU2SP3XoP4sv v+gUf+XxM7mZ7lTDHgl4DJCYVz2eWrh8bxcjFzIU0MA3Z7WNg6Xk8a936d7UMRxi5fS1 B3DTM6fEUAVWxQYgSZPmtoEXtPoL3j27VwIZUUj+BO/JhZojnSmxY1EKpbVYLZ99+4Wl 9o4A== 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=4uP8tM2rLUUa1UTW9Oahi30oxW8d9hGTydha3H13uOc=; b=ffXZoDBUXxuHgcfh84CVkPdlprQ7uY19IffOkp3ImACqKUjXOOySe0AYSqMDY4WJGh vll8glxWGZoY86rG9nEJ8dIC8bOVURx6CBZU1vXZ1+MjslBlt99LWRtYVG//FDdEox2D d4LTgD1VrhlkAtK2RfJKAExkFjpq/4eYkbtuU+uOlJTgpJ5E04nSuGtwcs5kIsHb1EWx e65joYtvYhImlpYa6PJ4UAFOV2NoVCF75RQA35BmeWAthHzFmbXNc55BnDG0WqMk16JQ UfGyjt1t+R/H0+IDEwG30qRKnrOs8jxlY2W2w/bIDGDzygdb/HJvKP/g1lnrKzHro02J tNkw== X-Gm-Message-State: AA+aEWYXmpccjKAjvy5SB56DheI8hPvDG6KwO+QyUR5VlMzWF7VoKEWn nCA9RfZTlC62NkMVcf8hN46AoA9bBVgEaDPtNHbCV8wR X-Google-Smtp-Source: AFSGD/VgyH7Na4xxtcEa7Pc4WEx1iChvJlDJsiLQKUpfpm87R0Ym4u0jOyQ6RD+VWPz6Rl2O64aVWlGyDPw2jFKRnZA= X-Received: by 2002:a0c:bd15:: with SMTP id m21mr17065563qvg.57.1543864724740; Mon, 03 Dec 2018 11:18:44 -0800 (PST) MIME-Version: 1.0 References: <6e53765f-52bd-f503-c1a5-ae23e402afcb@yuripv.net> <20181203072226.mpvh7an5pupjbwkb@ivaldir.net> <51d0fa8c-b453-69e0-500e-32818d29826a@yuripv.net> In-Reply-To: From: Warner Losh Date: Mon, 3 Dec 2018 12:18:33 -0700 Message-ID: Subject: Re: WITH_CTF breaks CD loader: "File too big" To: Yuri Pankov Cc: Baptiste Daroussin , FreeBSD Current X-Rspamd-Queue-Id: 67C8C69B65 X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.95)[-0.951,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.61)[ipnet: 2607:f8b0::/32(-1.65), asn: 15169(-1.29), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 19:18:46 -0000 On Mon, Dec 3, 2018 at 11:14 AM Yuri Pankov wrote: > Warner Losh wrote: > > On Mon, Dec 3, 2018 at 9:56 AM Yuri Pankov wrote: > > > >> Yuri Pankov wrote: > >>> Warner Losh wrote: > >>>> On Mon, Dec 3, 2018 at 8:10 AM Warner Losh wrote: > >>>> > >>>>> > >>>>> On Mon, Dec 3, 2018 at 12:24 AM Baptiste Daroussin > > >>>>> wrote: > >>>>> > >>>>>> On Sun, Dec 02, 2018 at 06:08:34PM +0300, Yuri Pankov wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Building disc1.iso using `make release` and having WITH_CTF set in > >>>>>>> src.conf leads to "File too big" displayed when booting the image. > >>>>>>> > >>>>>>> Would it make sense to build loader and related parts without CTF > >>>>>>> unconditionally as it doesn't look useful there? > >>>>>>> > >>>>>> > >>>>>> Fully agree with you > >>>>>> > >>>>> > >>>>> What a great Idea. We already turn it off in defs.mk: > >>> > >>> Sorry about that, I incorrectly assumed it wasn't done yet as there was > >>> a difference for me. > >>> > >>>>> MK_CTF= no > >>>>> > >>>>> which should be global to every single Makefile under stand. I'm not > >> sure > >>>>> why that's turning it back on. > >>>>> > >>>> > >>>> % cat /etc/src.conf > >>>> WITH_CTF=yes > >>>> FRED=present > >>>> % cd stand/cdboot > >>>> % make -V MK_CTF > >>>> no > >>>> % make -V FRED > >>>> present > >>>> % > >>>> > >>>> So this sure sounds like a false positive to me. Do you have logs > >> showing > >>>> cdboot building with MK_CTF=yes? > >>> > >>> Diff'ing the log for src/stand w/o and with -DWITH_CTF shows a lot of > >>> ctfconvert calls in the latter case. Attached is the diff of binary > >>> sizes in obj/ for stand/i386; could one of those be the problem I'm > >> seeing? > >> > >> If ctfconvert calls are indeed the source of problem, then something > >> seems to be wrong here (I didn't mention the "cdboot" binary exactly, > >> rather the binary it's trying to load): > >> > >> yuripv:~/ws/ctf/stand/i386/loader$ make -V MK_CTF -V CTFCONVERT_CMD > >> no > >> > >> yuripv:~/ws/ctf/stand/i386/loader$ make -DWITH_CTF -V MK_CTF -V > >> CTFCONVERT_CMD > >> no > >> ctfconvert -L VERSION ${.TARGET} > >> > > > > Ding! We have a winner: order of operations not quite right. We included > > src.opts.mk which includes bsd.own.mk which defines CTFCONVERT_CMD and > then > > we change the MK_CTF value which has no effect. Unlike the lazy > evaluation > > in makefile rules, where the last one wins, when we're parsing stuff for > > .if, it's the current value that's used. The solution is to include > > src.opts.mk later after we set the MK_foo overrides. > > > > r341433 should fix that. > > Thank you. > Please give it a spin and let me know if we're golden. I'll MFC it then since this should be in 12.1. Warner