[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[luto at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490

--- Comment #28 from Andy Lutomirski <luto at kernel dot org> ---
hjl, I don't understand what problem you're trying to solve here.  Your patch
makes it relatively straightforward to access global variables using __seg_gs
if the environment sets up the %gs base exactly the way GCC wants it to be set
up.

Why is this useful?

As far as I know, anyone using __seg_gs is trying to do something that is
outside the scope of what normal C code does.  They have some addressing model
that they want to use, and they're probably trying to access data that is *not*
a normal global variable.  On Linux, we want to use __seg_gs to access *percpu*
data, which is allocated by a fancy percpu allocator and relocated by the
kernel's internal relocation processing.  The latter is indeed based on data
emitted by binutils, but it is *not* a conventional ELF relocation engine.  It
will, of course, adapt as needed.

When I do:

extern int __seg_gs [insert more addressing details here?] variable;

int val = variable;

I am *not* trying to access something that would necessarily be credibly
defined by:

int __seg_gs [whatever] variable;

I'm trying to access something that is defined by a mechanism that is
completely invisible to gcc, may involve linker script magic, and may well
involve magic page table manipulation.

Also, please do not consider the stack cookie at %gs:0x28 to be a design
constraint in any respect.  We're talking about using a new GCC version to
solve problems that aren't cleanly solved on existing GCC.  That new GCC can
and should fix the silly stack cookie addressing, too, so it stops getting in
the way.