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 55950C433F5 for ; Mon, 23 May 2022 21:13:09 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6C6B583DBF; Mon, 23 May 2022 23:13:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Cq5f7Xxw"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 68A6F839BE; Mon, 23 May 2022 23:13:04 +0200 (CEST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 D651683DBF for ; Mon, 23 May 2022 23:13:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=alpernebiyasak@gmail.com Received: by mail-ej1-x62f.google.com with SMTP id gi33so22912306ejc.3 for ; Mon, 23 May 2022 14:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:cc :references:content-language:in-reply-to:content-transfer-encoding; bh=uoOLT7grKavXtj8IzWzNuaMaxQljy0OmOJaRIkexZuc=; b=Cq5f7Xxwg/Bg8/bisMFSYMcZ+k8qN4QjqG7AVBd9D3EXs5e0Q4HiM6FOmPBJdGTn7e wx4K+UoDdiiLmF9z2Jx+orZOva2zyfmmbMrcnZo2CLEKZyY525jqjtjztViP3uYeXylX SewJm/IKhI4zQssAJPmgirY4FJKqgdqPOYH4Ljsm0hkkEpXYY53NrRYvcfw6PDepvWp7 cxE3q3ScaYwnj3OT2p3XTihrQGDRMxhfhVDrCj6kBXMHb4zze9Wb4aqhDzOYRTe3/JVQ lJJP4IFDT1a6GmX4dgiXMFd097lNbnHWfLVdQKIkt3wPYh5S8IzZ39D8MKMtX89LyxNe Dg+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:cc:references:content-language:in-reply-to :content-transfer-encoding; bh=uoOLT7grKavXtj8IzWzNuaMaxQljy0OmOJaRIkexZuc=; b=vNYDQ1N8XnKuCNHet830JRjKheR/g/Etd7sckI6L0utmbnWTtft4jDvP/hYGhKVEF7 rMvWtZ8QSXpNypWE9M3/UudOUvOB7xE1QPh8taoAjqtt/QLlS+CO7sSztmcEOqBObayU pqpSnUWmsM7pzzkU0RPAUkSHhqYnx3skkIS96tByE/AJjL1TQhsf5HWliBWjo7CQkIxe LyZpO8SoakKDL4+C+uz9gsJjOIV2fEu1lR2O914U956xeuc6g7m33pol9NIqCkEByUP6 bHEv2yhi03mH9C1VTJC9qtXkNhNT7W9OhXqRmfOBsmMKYgyn1yXjr1Zzy2p2L+svKavF +Fog== X-Gm-Message-State: AOAM533mnY8KwYpj4QvjCq3aKpu/I3w6WeIQBnADgWUZA0OhkES2QADu uF8Xsvj3xLDWYgUkr7jeNOI= X-Google-Smtp-Source: ABdhPJxQBgo+KyGzwi4cNJ2UVGQ842BpgvHu1w6m9nC7CosNtsvxveXFR1VLIQEkhqQQtfaiqvAznQ== X-Received: by 2002:a17:906:a10a:b0:6fe:563a:8895 with SMTP id t10-20020a170906a10a00b006fe563a8895mr20869501ejy.80.1653340380383; Mon, 23 May 2022 14:13:00 -0700 (PDT) Received: from [192.168.0.74] ([178.233.178.185]) by smtp.gmail.com with ESMTPSA id m22-20020a1709060d9600b006feded0fa87sm1687152eji.218.2022.05.23.14.12.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 May 2022 14:12:59 -0700 (PDT) Message-ID: <7651ea81-d63d-2dca-9aa0-97cbb6b030c0@gmail.com> Date: Tue, 24 May 2022 00:10:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Alper Nebi Yasak Subject: Re: [PATCH V4 1/8] spl: guard u_boot_any with X86 To: Tom Rini 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" 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> <20220522145011.GK13239@bill-the-cat> Content-Language: en-US In-Reply-To: <20220522145011.GK13239@bill-the-cat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 22/05/2022 17:50, Tom Rini wrote: > On Sun, May 22, 2022 at 04:56:08PM +0300, Alper Nebi Yasak wrote: >> It looks like we should be able to change things in common/spl/spl.c to: >> >> #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 >> >> 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. I don't know, but the GCC manual says marking things 'unused' will suppress a warning if the variable is actually unused. I guess binman symbols may become unused due to some other config options being unset, and it's done for those cases? I think the optional symbols are marked weak just to signal the python side that they are optional. If I understand it right, binman: 1. Packs an image using the finalized 'spl/u-boot-spl.bin' 2. Figures out the image-pos and size values of every entry 3. Inspects the 'spl/u-boot-spl' ELF file for declared binman symbols 4. Raises an error if any non-'weak' symbol's value is undetermined 5. Updates the u-boot-spl.bin (in memory) with the calculated values 6. Recreates the final image based on that updated bin file.