Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1275846pxb; Thu, 24 Mar 2022 16:41:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhw7kiB66056Gkix+Te5h3sFyPirpSgSAXhOFq7Pay9W6NHCgAanNXURdtOJwj0a6ABLvM X-Received: by 2002:a05:6a00:23d3:b0:4fa:a9c7:2619 with SMTP id g19-20020a056a0023d300b004faa9c72619mr7621881pfc.36.1648165259799; Thu, 24 Mar 2022 16:40:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648165259; cv=none; d=google.com; s=arc-20160816; b=lrpDKgvlWmGKn87sbL6sKQ2g1/ZAN2XmOtYOw3zUxwc0/IaFRAz+J1DNLdJoKOCR1V ndaBIGPyFvrBccqSlF8sAiN/xF+N9P/FdQCiCgj2dlNFggA6+Hda/cgWxON/ZlkYXvIV XcFOq9zkltAhqXnK1LdvJR/KuxLGGjysTgzu6X5S7nOAPcqVLWrxxJt4Dqq/AeMFl9Ya LqNknGGwRaMKnMswYwEyksVQq5eVtZZ+7GDQKhKR9Ej2QBI7iirB4+vDuKcqbVYwZoBR 3qOUHZ0ly/5qfhq69ADTE+PAggt5woi6NX4MIP/GFco9THqmUz6gCEdKbkl/x7lpVaZ+ +nBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=mUzZpWtoiaz6qUyZgl4D/un66d/OEBm7XWnkAlJG284=; b=sWYFIDME8GOvqtlI8bNZM3Hz5L14RgdgcoFmjVptWdF1KYt9F2BJKLQGhk4+yc0aAn XBwxf6hDEc2WbUruiX6X6e3TKLEYu4TfQ8rd9+4pOQaNi7Ly5PVS+7RLBhrIXF5zGMks ysUkUTzAQSYRmI4Kh+wgbCRJe5L8SBOaMz/Hr63XI7zsAWuJcPbYDsQgMWk1I2K1uSPI 8PihSbTTvnSEWkqGx9gdf3cy1JCW3J21+jA4wLTvEA0zxwx4aYu4SQmxMHmz2Ut+ZRjZ 6sDGKXYYI1fr6YQHhTp2MZInrBJihfFOOUyfaVX98PhdWMIQSw3qRlcVO38Q/f+3sQdm 6LIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HJy7j2Km; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t8-20020a635348000000b003820d821f00si747917pgl.473.2022.03.24.16.40.44; Thu, 24 Mar 2022 16:40:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HJy7j2Km; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347095AbiCXBM2 (ORCPT + 99 others); Wed, 23 Mar 2022 21:12:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234269AbiCXBM0 (ORCPT ); Wed, 23 Mar 2022 21:12:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0CFF91AEB; Wed, 23 Mar 2022 18:10:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7E024B821DC; Thu, 24 Mar 2022 01:10:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5579C340E8; Thu, 24 Mar 2022 01:10:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648084253; bh=CsZP5UnSAKxZK3a75AHDxNk3N6tA7qLD8H2KhkTJABQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HJy7j2KmJIUPfXGjZpgJuLuo0cE1Na4spt86TjDCiY5dXQDs/1HONbDGUJz4m+zZ+ Jr3J8MUDbMwKep69i59cAcfHAz+oW0lPrUxgEAU/++LQN2DiT4jxH3vby+3Imp9Ng0 Uqqdn756Ar07iiSWUt5vHQxpdWX1rQPGLWmahEwMKZwC+bxnif9bxcNWV4NCBVVlfa wboCRx8yVXma7pXdL1Ns1zh1IF5xV0qgTOeYyM1Q5TqJ+Pd1Nor0uHMW5xd2Ij+DuZ 3Sy6sQRMpBjr96dnryEl/lAF/zFIBboLzpPjJwTdphVutmqhORwtvX20RQaHhz8733 +RIzPczgJVxsA== Date: Thu, 24 Mar 2022 10:10:48 +0900 From: Masami Hiramatsu To: Nick Desaulniers Cc: Sami Tolvanen , Padmanabha Srinivasaiah , Steven Rostedt , LKML , Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Nathan Chancellor , llvm@lists.linux.dev, Masahiro Yamada , Linux Kbuild mailing list Subject: Re: [PATCH v2 2/3] bootconfig: Support embedding a bootconfig file in kernel Message-Id: <20220324101048.c929020fd15bc14b50a3fff1@kernel.org> In-Reply-To: References: <164724890153.731226.1478494969800777757.stgit@devnote2> <164724892075.731226.14103557516176115189.stgit@devnote2> <20220316191649.GA11547@pswork> <20220318101445.fdb151efe58c6c3a1c572500@kernel.org> <20220321183500.GA4065@pswork> <20220322120311.690f237b63ddfd9c0e4f78ec@kernel.org> <20220322190219.GA26859@pswork> <20220323091617.495bfdf5281a543b27f2656f@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Nick, On Wed, 23 Mar 2022 10:11:53 -0700 Nick Desaulniers wrote: > On Tue, Mar 22, 2022 at 5:16 PM Masami Hiramatsu wrote: > > > > On Tue, 22 Mar 2022 20:02:19 +0100 > > Padmanabha Srinivasaiah wrote: > > > > > Hello Masami Hiramatsu, > > > > > > On Tue, Mar 22, 2022 at 12:03:11PM +0900, Masami Hiramatsu wrote: > > > > On Mon, 21 Mar 2022 19:35:00 +0100 > > > > Padmanabha Srinivasaiah wrote: > > > > > > > > > Hello Masami Hiramatsu, > > > > > > > > > > On Fri, Mar 18, 2022 at 10:14:45AM +0900, Masami Hiramatsu wrote: > > > > > > On Wed, 16 Mar 2022 20:16:49 +0100 > > > > > > Padmanabha Srinivasaiah wrote: > > > > > > > > > > > > > Hello Masami Hiramatsu, > > > > > > > > > > > > > > Also noted that a change in default.bconf requries a clean build, is it > > > > > > > expected behaviour? > > > > > > > > > > > > default.bconf will be always updated if CONFIG_EMBED_BOOT_CONFIG=y. So you can > > > > > > do incremental build. (I tested it with the incremental build environment) > > > > > > > > > > > > > > > > Thanks, your observation made me to further experiment ther incremental build. > > > > > > > > > > Below are the observations I have: > > > > > > > > > > When I use GCC for a build; yes, the modified default.conf was observed on > > > > > the target. > > > > > > > > > > But when I use clang; either with FULL or THIN LTO, the modified > > > > > default.conf doesnt get reflected on the target. > > > > > > > > Hmm, curious. So you just add 'CC=clang' on the make command line, right? > > > Yes, CC=clang ARCH=arm64 LLVM=1. As specified here: > > > https://docs.kernel.org/kbuild/llvm.html. > > You should just need LLVM=1 (and ARCH=arm64) at this point. LLVM=1 > implies CC=clang. OK. > > Also, here's the start of the lore thread for folks: > https://lore.kernel.org/linux-doc/164724892075.731226.14103557516176115189.stgit@devnote2/ Thanks for the link! > > > > > > > > Can you confirm that following line in your build log, > > > > > > > > GEN lib/default.bconf > > > > > > > Yes, I do see above line. Indeed lib/default.bconf will get incremental > > > change. > > > > > > GEN lib/default.bconf > > > CC lib/bootconfig.o > > > AR lib/lib.a > > > > > > > and the timestamp of lib/bootconfig.o is built after lib/default.bconf file? > > > > > > > Yes, verified timestamp for all above artifacts including vmlinux.o. > > > > > > ex: > > > -rw-rw-r-- 1 psrinivasaia psrinivasaia 22K Mar 22 14:50 > > > ../out/lib/bootconfig.o > > > -rw-rw-r-- 1 psrinivasaia psrinivasaia 355 Mar 22 14:50 > > > ../out/lib/default.bconf > > > -rw-rw-r-- 1 psrinivasaia psrinivasaia 54M Mar 22 14:50 ../out/vmlinux.o > > > > > > As said incremnetal change was refelected in artifact default.bconf. > > > But not in vmlinux.o/vmlinux, used below command to verify. > > > > Interesting! This sounds clang's issue, because the make command rebuilds > > the object file including new default.bconf, but the linker (lld?) > > doesn't link it again correctly. > > Sounds like missing FORCE directives in the Makefiles, perhaps? Hmm, as you can see in my patch, the default.bconf (contents) already has the FORCE directive as below. +ifeq ($(CONFIG_EMBED_BOOT_CONFIG),y) +# Since the specified bootconfig file can be switched, we forcibly update the +# default.bconf file always. +$(obj)/default.bconf: FORCE + $(call cmd,defbconf) + +quiet_cmd_defbconf = GEN $@ + cmd_defbconf = cat < /dev/null $(CONFIG_EMBED_BOOT_CONFIG_FILE) > $@ +clean-files += default.bconf +$(obj)/bootconfig.o: $(obj)/default.bconf +endif And since bootconfig.o depends on the default.bconf, it is at least compiled as Padmanabha reported above. If I missed something, please tell me. > > Sami, do you recall any issues like this when implementing > commit dc5723b02e52 ("kbuild: add support for Clang LTO") > ? > > > > > > > > > llvm-objdump -s -j .init.data ../out/vmlinux > > > > > > On target too, /proc/bootconfig shows old data. > > > > > > > And is that related to CONFIG_LTO? What happen if CONFIG_LTO=n? > > > > > > > Yes; CONFIG_LTO_NONE=y issue not observed even with LLVM binutils. > > > > And this issue is related to LTO. Maybe LTO ignores the '.init.data' > > section update. (Perhaps, LTO only checks the function code hash or > > something like that instead of the timestamp, and ignore whole object > > file if all of them are not updated.) > > Sounds like this is a result of the above issue? As I said above, I used FORCE for the default.bconf and confirmed that the bootconfig.c is compiled (updated). Thus I think FORCE correctly works. I'm not sure how LTO is implemented, but if the LTO works based on the intermediate representation(IR), I guess it doesn't handle inline asm ".incbin" directive in IR. I mean if the linker only checks the inline asm as a "string" in the .c file, it will miss the update of the contents of .incbin directive, because inline asm code itself is not changed. However the object file itself is updated, since the .incbin directive embeds an external file to the object file. This is just my guess. I would like to ask LLVM maintainers to help checking the safeness of using ".incbin" directive with LTO. (Note that this is also affects other parts which uses .incbin, like /proc/config.gz) Thank you, -- Masami Hiramatsu