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;
Message-ID: <2008526a-e0ca-7e67-cff6-b540d62e58c7@kernel.org>
Date:   Wed, 26 Oct 2022 10:35:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Content-Language: en-US
To:     Michael Matz <matz@suse.de>
Cc:     Masahiro Yamada <masahiroy@kernel.org>,
        linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arch@vger.kernel.org,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nathan Chancellor <nathan@kernel.org>,
        =?UTF-8?Q?Martin_Li=c5=a1ka?= <mliska@suse.cz>,
        Borislav Petkov <bpetkov@suse.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Ard Biesheuvel <ardb@kernel.org>
References: <20220924181915.3251186-1-masahiroy@kernel.org>
 <20220924181915.3251186-7-masahiroy@kernel.org>
 <ea468b86-abb7-bb2b-1e0a-4c8959d23f1c@kernel.org>
 <alpine.LSU.2.20.2210251210140.29399@wotan.suse.de>
From:   Jiri Slaby <jirislaby@kernel.org>
Subject: Re: [PATCH v3 6/7] kbuild: use obj-y instead extra-y for objects
 placed at the head
In-Reply-To: <alpine.LSU.2.20.2210251210140.29399@wotan.suse.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 25. 10. 22, 14:26, Michael Matz wrote:
>> Ideas, comments? I'll send the attachment as a PATCH later (if there are
>> no better suggestions).
> 
> This will work.  An alternative way would be to explicitly name the input
> file in the section commands, without renaming the section:
> 
> @@ -126,6 +126,7 @@ SECTIONS
>                  _text = .;
>                  _stext = .;
>                  /* bootstrapping code */
> +               KEEP(vmlinux.a:head64.o(.head.text))
>                  HEAD_TEXT
>                  TEXT_TEXT
> 
> But I guess not all arch's name their must-be-first file head64.o (or even
> have such requirement), so that's probably still arch-dependend and hence
> not inherently better than your way.

The downside of this is that it doesn't make sure the function 
(startup_64()) is the first one. When someone sticks something before 
it, it breaks again. But leaving the decision up to the x86 maintainers ;).

Re. other archs, I have absolutely no idea (haven't looked into that at 
all).

thanks,
-- 
js