From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C0EE23717F for ; Sat, 20 Dec 2025 00:48:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766191724; cv=none; b=DUbDM+btC0zASIFMZ+JttrNYQiw2NjXIGHmoRZ/aeZP9B9Jgbi7y558IRf8Kx9lq9tAjoDqYFY7WZ+Y+/oV1I1kUxAweMAG23uKyyHcqZT/jOYjgpPSHQ341gJyC7KYlJwAfP/4OYtCEQSFiER78Fe+StRk95MUlYhGiJdx21VE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766191724; c=relaxed/simple; bh=txvC4eIHoIbXUgJ696ry0IvPqAOP1iC6/KkH7/WVutI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A3EIUYERIqxI0f+Efw6sTfgbm8SXiOzwEyUVQosaItStOmTAsuZMgANfjrP+t3KK7Gl4yiTo4tNe7g5vorNe2k4foIfcgf28Z9qq0tl0eUY18DK3p3xUYOGx4JjAzpWpxc1cFjsSI9dsm5ZBTDm2FjddxHEe2t2d71YQq20BZro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=M9KUMHUb; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="M9KUMHUb" Received: from [IPV6:2601:646:8081:9483:a140:2beb:fe7:432d] ([IPv6:2601:646:8081:9483:a140:2beb:fe7:432d]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 5BK0m2M6936293 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 19 Dec 2025 16:48:35 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 5BK0m2M6936293 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025112201; t=1766191715; bh=5d3MnFE6c5O/PLOf1sDe0JbX2BkVUKwcBfxri7l7flA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=M9KUMHUb2Sp/RFVaZc/F7EsGXUQHaMEatHWHDxlYmOOJZ39zFHGK3NNqYgCBAM4rT VmgYtydm1oTMd+KF95yBwDJUvDxcDaIBbMd4fNFz4f85uc7YZYXSeQ/eao8BTT6dWM t5/r50sjG7VX1zkJOLEycKP5Gmwm78R4Do8CsfO3SUcMYvNaY38ghFt1k6u2olk/nS k1h2izLSReG4yA30F8fRotHfEOl4InA+Yx272bL10leCeEwZt5KGa6FrdtDyj0cKMr vHtOV6FQEzaPjv10pj1pIn6tDwtJlJC3rAcZaAAdpMN7gQzy9n8xE7ZWNnjsfPOc2R Jz5hht3Sb5kQQ== Message-ID: <74706dc9-79bf-4f8c-a4e6-88fc5289998e@zytor.com> Date: Fri, 19 Dec 2025 16:47:57 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Do we still care about compilers without __seg_fs and __seg_gs support?? To: Nathan Chancellor Cc: Uros Bizjak , Nick Desaulniers , Bill Wendling , Justin Stitt , "x86@kernel.org" , LKML , Andrew Morton References: <20251220002424.GA3998744@ax162> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20251220002424.GA3998744@ax162> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2025-12-19 16:24, Nathan Chancellor wrote: > On Fri, Dec 19, 2025 at 03:24:21PM -0800, H. Peter Anvin wrote: >> As of Linux 6.16, we require: >> >> gcc 8.1 or higher >> clang 15.0.0 or higher >> >> If my reading of the release notes is correct, then both versions *should* >> supported __seg_fs and __seg_gs, but we have: >> >> config CC_HAS_NAMED_AS >> def_bool $(success,echo 'int __seg_fs fs; int __seg_gs gs;' | $(CC) -x >> c - -S -o /dev/null) >> depends on CC_IS_GCC >> >> We don't even try on clang. >> >> Being able to actually rely on the compiler for this would make a lot of >> things cleaner. For one thing, I'm trying to untangle a bunch of ugliness in >> the code sharing between realmode and proper flat mode code... >> >> Uros, you seem to have touched this code as recently as earlier this year; any >> thoughts? >> >> What about the LLVM people, any insights? > > Trying to use __seg_fs or __seg_gs in certain cases crashes the X86 > backend. > > https://github.com/llvm/llvm-project/issues/93449 > > Is there anyone on AMD or Intel's LLVM teams that could look into > solving that? Nick pinged a couple of Intel's folks but it does not look > It looks to me that this is specifically related to static initializers, or is there something else here that I'm not sure about? I'm asking because it might still allow at least the boot code improvements, and/or have some other less painful workaround than carrying these hacks. As far as I can tell, on x86 gcc will not change the value of the pointer when cast to a different address space and I believe Linux expects this behavior. -hpa