From nobody Fri Nov 15 08:40:44 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XqVpl1HkLz5cqxm for ; Fri, 15 Nov 2024 08:40:47 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XqVpl0nvXz49yG; Fri, 15 Nov 2024 08:40:47 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731660047; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zzSpad+1lSL+TtlRTq3oZjEVAJQPdUOLEkk0amSRfpY=; b=o6ZXhDLbJYRYDhmCXxmrePU6sb9BL48gRD/fOZdzdRATof+H3G2uX3014kVbWDQlKj2fLq x+KTDM9EMfzhI7vV8oUFD3EIOxILTYcW/vvoVU7j8+pCYvdFJavtf7jcngW3/IReWz7mVx y0yYGNc/lvprE4YkyVYxQdnDtQ5DR0Nw5omX6p2S/ts0M3OfwvKTvpQz39VLKsiFdUeZdl J4bvEPGnBnvBrZM29rAPSq+7iHSMSMOUnIw09VrigKAqmDk4IclNaz86kwfpiVcoJ+SZEk CJ8OOwn93HY357uZLmifESGHOOLaPYTQYuXPbt5eXJZrRwh1UfHJKf8B/cWhaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731660047; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zzSpad+1lSL+TtlRTq3oZjEVAJQPdUOLEkk0amSRfpY=; b=wUp2ZF1y52pHI16GYcwlYf/74TukXByPpz9uu7YjwqgGpU1w6o+vYfn1zz++w72W4t09MW HzCcBfdNetAb7VtmpuEXBpreVAfqT0yyoLk1fjzktgTbiMVBqGj60ZIIlP3pLCeH5Ivylx jg+oCWYeReMrja9fMpegwJvc+zl3ujb1iSpTO/vt/+WSaf0UY8rsfnjT+f1/px6jJ+FZSS PHelfi1A9Hv+wIdlgcGcO5e56hPzfnJvs69tEgkGFTXI0qtYsRT7LVoYr398CPFxvM4kJc sTwU/GNWv9uaCHWYpouTHX/9rEFiLl4pSA2GnDPqzQiZVBf+g5BCl6gEoFjQ6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731660047; a=rsa-sha256; cv=none; b=LO2zs78EJUspFNwuqyKr4Y+K+CP8433IT0UL5RDmuFvFTzjfhwgUckMGQ+zK1SPE9tpnG7 hMZXaVUEckZUqIz1bZdll4EmSn5XdD15W1Vm1kqlVMrHI0xSvVkAt6mIQ7QPEI3zQVQhnP qA1eUmgNPY+78h14zOBercGLnMXNVo208WqTtFfaNEvx05Rl2AjbeXOzWFAYvo5ni52E97 +Z9xV4ayroqw6/yEh1WHjZ4ENemnlEutlKElvK+6+7VCWii0TfdzJqM7sm41oxXl2UUDXR 3HgTWuIFmMyu79FvB37R0GLpPq4AbSICEak79FqW0T4b3Nm6cK+YcbDltpFP6w== Received: from [192.168.168.195] (internet-251.radiolinkplus.cz [109.205.241.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XqVpk2cLVz1M30; Fri, 15 Nov 2024 08:40:45 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: Date: Fri, 15 Nov 2024 09:40:44 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: "mmel@freebsd.org" Reply-To: mmel@FreeBSD.org Subject: Re: llvm19 lld issue To: Dimitry Andric Cc: FreeBSD Current References: <192a3da4-6765-401a-a669-0359f8ac9487@FreeBSD.org> <8C24BC41-9782-45C9-AB8B-075943452519@FreeBSD.org> Content-Language: cs, en-US In-Reply-To: <8C24BC41-9782-45C9-AB8B-075943452519@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14.11.2024 22:01, Dimitry Andric wrote: > On 14 Nov 2024, at 13:44, Michal Meloun wrote: >> >> While searching for the cause of armv7 kernel corruption after updating to llvm19 lld, I came across an interesting problem. >> >> - The linker script does not list all generated sections. Specifically, the data sections created by the linker set are not listed. >> >> - The linker can place these orphaned sections in any location (OK, with some restrictions). See https://maskray.me/blog/2024-06-02-understanding-orphan-sections. >> >> - Creating symbols outside a section is fragile and subject to error; the linker may place an orphaned section between the symbol definition and the following section. >> >> We ran into this problem many years ago, see https://github.com/freebsd/freebsd-src/commit/6e764e36da019837d90e3b4b712871ee4442637a. Unfortunately, we didn't fix it completely then, and we have to address the same corruption again. >> >> I think we should be strict in this area and use '--orphan-handling=error' for kernel linking. However, I'm not sure we can handle linker sets gracefully. >> >> Any comments, contrary opinion or better solution ? Does anyone know how to properly list all linker sets (mainly but not only 'set__set') in linker script and which section is appropriate for them ? .rodata? > > I tried adding --orphan-handler=error, and on buildkernel (even for amd64) I get pretty soon: > > --- all_subdir_accf_data --- > ld: error: accf_data.o:(.data) is being placed in '.data' > ld: error: accf_data.o:(set_modmetadata_set) is being placed in 'set_modmetadata_set' > ld: error: accf_data.o:(set_sysinit_set) is being placed in 'set_sysinit_set' > ld: error: accf_data.o:(.debug_loc) is being placed in '.debug_loc' > ld: error: accf_data.o:(.debug_abbrev) is being placed in '.debug_abbrev' > ld: error: accf_data.o:(.debug_info) is being placed in '.debug_info' > ld: error: accf_data.o:(.debug_ranges) is being placed in '.debug_ranges' > ld: error: accf_data.o:(.debug_str) is being placed in '.debug_str' > ld: error: accf_data.o:(.comment) is being placed in '.comment' > ld: error: accf_data.o:(.debug_frame) is being placed in '.debug_frame' > ld: error: accf_data.o:(.debug_line) is being placed in '.debug_line' > ld: error: accf_data.o:(.llvm_addrsig) is being placed in '.llvm_addrsig' > ld: error: accf_data.o:(.SUNW_ctf) is being placed in '.SUNW_ctf' > ld: error: :(.note.gnu.build-id) is being placed in '.note.gnu.build-id' > ld: error: :(.note.GNU-stack) is being placed in '.note.GNU-stack' > ld: error: :(.symtab) is being placed in '.symtab' > ld: error: :(.shstrtab) is being placed in '.shstrtab' > ld: error: :(.strtab) is being placed in '.strtab' > --- all_subdir_aic7xxx --- > --- all_subdir_aic7xxx/ahc --- > --- machine --- > machine -> /home/dim/src/freebsd/src/sys/amd64/include > --- all_subdir_accf_data --- > *** [accf_data.ko.full] Error code 1 > > > Not sure if those are all really orphaned, though? > > -Dimitry > Most of them are not orphaned and I think they should be explicitly placed. Annoying as it is, we should probably keep a list of sections used in the kernel (one is sufficient for all architectures) and include it in the ldscripts for a particular arches(it's about 24 lines now). After discussion with jrtc27 (thanks a lot for your patience), I think we have only three options besides explicitly listing all kernel sections: 1) Leave the ldscripts as they are, but prefix each _start symbol with a guard, i.e. explicit assignment to location counter ( '.=.' or ALIGN()). 2) Move all _start/end symbols defined outside to the appropriate sections 3) Add the linker '--orphan-handling=error' and declare/discard all compiler-generated sections. I definitely don't like option 1. It's too fragile and depends on not very defined linker behavior. Option 2 is easy and robust, and with the explicit placement of all kernel sections seems sufficient. In my best opinion, we can combine options 2 and 3 to get the most robust solution. Another problem is that an explicit list of kernel sections could probably make modules outside the tree interact badly with linker script. What was your preference? Michal