https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #14 from Andy Lutomirski <luto at kernel dot org> --- (In reply to H. Peter Anvin from comment #13) > On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com > <gcc-bugzi...@gcc.gnu.org> wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 > >OTOH, we can avoid RIP relative addresses for non-default address > >spaces, when > >-mcmodel=kernel compile flag is in effect. > > It's not just about the kernel model. The example I have is for the > small-pic model. We are considering moving away from the kernel model. The kernel, and possibly future userspace, can use very strange relocations for non-standard segments. The actual percpu space is some contiguous (presumably) block that starts at some offset from the actual GS base, but that offset is flexible. There are several possible models: a) Percpu data starts at %gs:0 (or %gs:small number) and access uses absolute addressing. This means that percpu symbols will resolve to numbers between 0 and 2G and do *not* change if the kernel is relocated. b) Percpu data starts at %gs:0 (or %gs:small number) and access uses rip-relative addressing. This requires that the kernel be located at a very high address so that the percpu data is reachable. Percpu symbols are largish numbers but still less than 2G. The symbols do change if the kernel is relocated (which is totally the opposite of normal PIC addressing, where PIC offsets are not relocated). (a) and (b) could plausibly coexist with appropriate magic in the symbol tables. c) Percpu data starts at %gs:x where x is the kernel load address plus a smallish constant. Access is like %gs:symbol(%rip). No dynamic relocations. Also no constraints on where the kernel is loaded. d) Percpu data starts at %gs:x where x is the kernel load address plus a smallish constant. Access is like %gs:symbol. There are dynamic relocations. Different choices here have different tradeoffs, and, for any given kernel code model, more than one of these is possible. I don't think -mcmodel should be the determining factor. (Models c and d would require gcc to allow a flexible stack cookie location.)
