Do we still care about compilers without __seg_fs and __seg_gs support??

Do we still care about compilers without __seg_fs and __seg_gs support??

[H. Peter Anvin]

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?

	-hpa

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[Nathan Chancellor]

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

Cheers,
Nathan

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[H. Peter Anvin]

On 2025-12-19 16:24, Nathan Chancellor wrote:
> 
> 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
> 

I don't know. As you know... things have been a bit crazy around these parts
lately.

	-hpa

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[H. Peter Anvin]

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

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[Uros Bizjak]

On Sat, Dec 20, 2025 at 1:48 AM H. Peter Anvin <hpa@zytor.com> wrote:
>
> 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.

This is because "... these address spaces are not considered to be
subspaces of the generic (flat) address space. This means that
explicit casts are required to convert pointers between these address
spaces and the generic address space. In practice the application
should cast to uintptr_t and apply the segment base offset that it
installed previously." [1]

[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Uros.

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[H. Peter Anvin]

On December 19, 2025 11:50:57 PM PST, Uros Bizjak <ubizjak@gmail.com> wrote:
>On Sat, Dec 20, 2025 at 1:48 AM H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> 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.
>
>This is because "... these address spaces are not considered to be
>subspaces of the generic (flat) address space. This means that
>explicit casts are required to convert pointers between these address
>spaces and the generic address space. In practice the application
>should cast to uintptr_t and apply the segment base offset that it
>installed previously." [1]
>
>[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
>
>Uros.
>

... which makes sense.

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[Uros Bizjak]

On Sat, Dec 20, 2025 at 12:24 AM H. Peter Anvin <hpa@zytor.com> 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?

To enable __seg_gs support with clang, you will first need the patch at [1].

Second, clang does not emit %gs: prefix by itself when the address
from __seg_gs named address space is used in asm(). This can be worked
around by leaving  __percpu_arg(x) defined to __percpu_prefix "%" #x
for clang.

Finally, you will hit issue #93449.

[1] https://lore.kernel.org/lkml/20240526175655.227798-1-ubizjak@gmail.com/

Uros.

Re: Do we still care about compilers without __seg_fs and __seg_gs support??

[H. Peter Anvin]

On December 19, 2025 11:47:50 PM PST, Uros Bizjak <ubizjak@gmail.com> wrote:
>On Sat, Dec 20, 2025 at 12:24 AM H. Peter Anvin <hpa@zytor.com> 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?
>
>To enable __seg_gs support with clang, you will first need the patch at [1].
>
>Second, clang does not emit %gs: prefix by itself when the address
>from __seg_gs named address space is used in asm(). This can be worked
>around by leaving  __percpu_arg(x) defined to __percpu_prefix "%" #x
>for clang.
>
>Finally, you will hit issue #93449.
>
>[1] https://lore.kernel.org/lkml/20240526175655.227798-1-ubizjak@gmail.com/
>
>Uros.
>

Yeah. It's sad that compatibility functionality seems to be as low on the priority list as it is. However, it looks like it might still be possible to do the boot code cleanups even within the limitations of the current clang, bugs and all...