https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Andy Lutomirski from comment #14) > (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. Case (a) above looks like global-pointer access. Global pointer (%gs) points to the start (or perhaps in the middle (?) ) of the GP-accessible section. This section can be placed anywhere, as long as all data is reachable with GP+-offset. In x86 case, offset can be +-2GB for small model. Changing GP by some small value would access different instance of (percpu) data block. Case (b) is weird, since all data access is GP relative, even when absolute offsets are used. I fail to see benefits of using relative relocations against %rip and %gs. When kernel is relocated, GP remains the same, when GP-accessible section is relocated, GP needs to be updated to point to new location. To implement the case (a) above, we'd need some new relocations against global-pointer. > 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. This is the current implementation, (d) can be implemented with the patch from comment #15, but assuming kernel text+data must fit in 2GB, there would be no benefits. Code size will increase a bit for no benefit.
