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.