From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5FFCAC433F5 for ; Sun, 22 May 2022 14:50:26 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4ECC683E8E; Sun, 22 May 2022 16:50:23 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="YOQjsOCu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CB28383EB4; Sun, 22 May 2022 16:50:20 +0200 (CEST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5D5F883E36 for ; Sun, 22 May 2022 16:50:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x830.google.com with SMTP id 11so8809536qtp.9 for ; Sun, 22 May 2022 07:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uky6+2Wje70UXa6PfZu8aM5uChaUXpbD6Plr4eDyukw=; b=YOQjsOCuUMKsnUCxRqjHC1wW/YeiMZ4/f9ggdqS1OO7EKZ1JGKGOo4ER6ntg1m5Jto 9Ro8TdlkBXepiLNADFd96gHp919pKg7kxi8Nj6slgFSO78kjHu9ktFOAWyfKnlRoQxM6 9oJuyiXa7bvMt582nC42DJK/TaRXb5AmcEYsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uky6+2Wje70UXa6PfZu8aM5uChaUXpbD6Plr4eDyukw=; b=1lrGPRvyjchCXvERA7pYq8/MltjxgOKgi0sCXAnO59vAGNl7kUy/B5shr6InYfShwQ //23Z/fPcRAmVVNMewUsEccVDuAzTpGAqbcveqB2J5JJcVDv5ZpAXFrRi5TsJlJJA22f 1Fe2xxrtCpRhc009N8ft/uI8Kf2RqcZOGbbhCefvEVLorObnQB238tvu3IAoeofWkyiB 1f2N46G07tHoI3NxTJ5PIqy8vYuLOf7oYyXu5R3atKtJTlT4RQEPaXXOhRZjB07hxZ9E 3qqO9JGGpl+594mjsb2ZrWfOk3V7Cw8vkC0IlENRty35ehNk8eRRrMbQssfN667Rehay 0vmQ== X-Gm-Message-State: AOAM533U+DIpnppvqkGNXkjltpJjpO9+6faFpKQzVGI7TEr/v78jSMeO b3IsOueKp/9Ryc3SWCAUjVMnIw== X-Google-Smtp-Source: ABdhPJxf88Y/9V9s8qe3+IzWZbc2zHri/8HVAqy8z1ftTGav4BENxEZk/zh5lYOw4NnMpviV7gGZyg== X-Received: by 2002:a05:622a:1651:b0:2f3:e153:ebac with SMTP id y17-20020a05622a165100b002f3e153ebacmr13521854qtj.23.1653231016035; Sun, 22 May 2022 07:50:16 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-25fd-0000-0000-0000-1003.res6.spectrum.com. [2603:6081:7b00:25fd::1003]) by smtp.gmail.com with ESMTPSA id g18-20020a05620a279200b006a39b530fadsm24593qkp.37.2022.05.22.07.50.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 May 2022 07:50:15 -0700 (PDT) Date: Sun, 22 May 2022 10:50:11 -0400 From: Tom Rini To: Alper Nebi Yasak Cc: Peng Fan , "Peng Fan (OSS)" , "sbabic@denx.de" , "festevam@gmail.com" , "ariel.dalessandro@collabora.com" , "michael@amarulasolutions.com" , "tharvey@gateworks.com" , "sjg@chromium.org" , "marek.behun@nic.cz" , "pali@kernel.org" , "sr@denx.de" , Ricardo Salveti , "patrick.delaunay@foss.st.com" , "u-boot@lists.denx.de" Subject: Re: [PATCH V4 1/8] spl: guard u_boot_any with X86 Message-ID: <20220522145011.GK13239@bill-the-cat> References: <20220520141048.20034-1-peng.fan@oss.nxp.com> <20220520141048.20034-2-peng.fan@oss.nxp.com> <20220520152127.GC13239@bill-the-cat> <20220521120518.GI13239@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2VXyA7JGja7B50zs" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean --2VXyA7JGja7B50zs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 22, 2022 at 04:56:08PM +0300, Alper Nebi Yasak wrote: > On 21/05/2022 15:05, Tom Rini wrote: > > On Sat, May 21, 2022 at 08:33:56AM +0000, Peng Fan wrote: > >>> Subject: Re: [PATCH V4 1/8] spl: guard u_boot_any with X86 > >>> > >>> On Fri, May 20, 2022 at 10:10:40PM +0800, Peng Fan (OSS) wrote: > >>> > >>>> From: Peng Fan > >>>> > >>>> set the symbol as weak not work if LTO is enabled. Since u_boot_any = is > >>>> only used on X86 for now, so guard it with X86, otherwise build break > >>>> if we use BINMAN_SYMBOLS on i.MX. > >>>> > >>>> Tested-by: Tim Harvey #imx8m[m,n,p]-venice > >>>> Signed-off-by: Peng Fan > >>>> --- > >>>> common/spl/spl.c | 8 ++++++-- > >>>> common/spl/spl_ram.c | 4 ++++ > >>>> 2 files changed, 10 insertions(+), 2 deletions(-) > >>> > >>> I think we long term need to figure this out and address it so LTO wo= rks. But > >>> for now can you please guard this with a test on LTO instead, so it's= clear > >>> where the problem is? > >> > >> Sorry, I could not get your point about guard with a test on LTO. > >> > >> Actually binman weak symbol will report a warning log if there is no u= _boot_any > >> binman symbol. Since only X86 use it, I guard with X86. > >=20 > > Why are you mentioning LTO in the commit message? When I read the > > commit message it sounds like you're saying the problem is that LTO > > doesn't like how this symbol is handled, but if LTO was disabled, > > everything would be fine. If it's not LTO-related, please re-word the > > message instead. >=20 > It looks like we should be able to change things in common/spl/spl.c to: >=20 > #if CONFIG_IS_ENABLED(BINMAN_SYMBOLS) > /* See spl.h for information about this */ > binman_sym_declare_optional(ulong, u_boot_any, image_pos); > binman_sym_declare_optional(ulong, u_boot_any, size); > #endif >=20 > which would mark the symbol as 'weak' and turn the error into a warning > on the binman side. But that is somehow being undone by LTO. So, looking at binman_sym_declare_optional we tell the linker that it's weak and might even be unused. LTO gets very aggressive about finding things that aren't used in the resulting binary and discarding them. Typically we have the problem of a function that is used but it's hard for LTO to see it, so we give it the "used" attribute. But for something we're already saying is "unused" this would be wrong. So why do we mark things as unused here? I assume it's marked weak as it could be overridden at link time by a definition elsewhere. --=20 Tom --2VXyA7JGja7B50zs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmKKTZ8ACgkQFHw5/5Y0 tyzqEgv+OVV0jk3CGNkSTekcTa1jRa5ql9vphnd2t3cRYd/dudCPJviFTme6hPTz JD4lR+xGAujz0uz2Y8qs39dIDShUxIQ3QLZxOFfSEVQWvRme4WXIS95wyPQIqAAg 1zfxG+1eV4+Gex6au0TBmToT3mNxG6ZBYZk7qK5pXP3wqUtoDlX8Os6CaJ0w/Qrc Nv99cwbz+Jv+CymX9xbsREGdSXv6VD5igiIwqC2lCCLEfIPIPXcPOmwja97eVzL7 kMFj/gBZ+z0yKNAd4LytwvTjObpDgNcZhvj3T55AhNOMkv/XBTDpVWr9dHo59WKC bR0jiFVuZAe9o/d3uXlOpgMb2D9jf8sBvQ2Axda82rA8nZo49j/kCochZJ7x+VXt or7EbJxm2jjMxdp6psXyNLvXE+oxLTwAfk2HXQCKG+oVoA2pHi56rtyS1mff+zeY InHkMnCA+A4VMm8ZhlHKne7kbuJksAZenYVTticK72ZuAZO3c912iAyJwpRGwxHq iyeVFAAt =rbNv -----END PGP SIGNATURE----- --2VXyA7JGja7B50zs--