[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC 00/15] x86_64: Optimize percpu accesses
    Jeremy Fitzhardinge <> writes:

    > It's just the stack canary. It isn't library accesses; it's the code gcc
    > generates:
    > foo: subq $152, %rsp
    > movq %gs:40, %rax
    > movq %rax, 136(%rsp)
    > ...
    > movq 136(%rsp), %rdx
    > xorq %gs:40, %rdx
    > je .L3
    > call __stack_chk_fail
    > .L3:
    > addq $152, %rsp
    > .p2align 4,,4
    > ret
    > There are two irritating things here:
    > One is that the kernel supports -fstack-protector for x86-64, which forces us
    > into all these contortions in the first place. We don't support stack-protector
    > for 32-bit (gcc does), and things are much easier.

    How does gcc know to use %gs instead of the usual %fs for accessing
    the stack protector variable? My older gcc-4.1.x on ubuntu always uses %fs.

    > The other somewhat orthogonal irritation is the fixed "40". If they'd generated
    > %gs:__gcc_stack_canary, then we could alias that to a per-cpu variable like
    > anything else and the whole problem would go away - and we could support
    > stack-protector on 32-bit with no problems (and normal usermode could define
    > __gcc_stack_canary to be a weak symbol with value "40" (20 on 32-bit) for
    > backwards compatibility).
    > I'm close to proposing that we run a post-processor over the generated assembly
    > to perform the %gs:40 -> %gs:__gcc_stack_canary transformation and deal with it
    > that way.

    Or we could do something completely evil. And use the other segment
    register for the stack canary.

    I think the unification is valid and useful, and that trying to keep
    that stupid stack canary working is currently more trouble then it is


     \ /
      Last update: 2008-07-09 22:35    [W:0.025 / U:60.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site