Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:

Yes, and there's no reason we couldn't do the same on 64-bit, aside
from the stack-protector's use of %gs:40. There's no code-size cost
in large offsets, since they're always 32-bits anyway (there's no
short absolute addressing mode).

If we manually generate %gs-relative references to percpu data, then
it's no different to what we do with 32-bit, whether it be a specific
symbol address or using the TLS relocations.


If we think the problem is the zero-basing triggering linker bugs, we
should probably just use a small offset, like 64 (put a small dummy
section before the .percpu.data section to occupy this section.)

I'm going to play with this a bit and see if I come up with something
sanish.

-hpa

One interesting thing I've discovered is the gcc --version may make a
difference.

The kernel panic that occurred from Ingo's config, I was able to replicate
with GCC 4.2.0 (which is on our devel server). But this one complained
about not being able to handle the STACK-PROTECTOR option so I moved
everything to another machine that has 4.2.4, and now it seems that it
works fine. I'm still re-verifying that the source bits and config options
are identical (it was a later git-remote update), and that in fact it is
the gcc --version, but that may be the conclusion. (My code also has some
patches submitted but not yet included in the tip/master tree. Curiously
just enabling some debug options changed the footprint of the panic.)

Are we allowed to insist on a specific level of GCC for compiling the
kernel?

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
    ... in large offsets, since they're always 32-bits anyway (there's no ... about not being able to handle the STACK-PROTECTOR option so I moved ... I'm still re-verifying that the source bits and config options ... the gcc --version, but that may be the conclusion. ...
    (Linux-Kernel)
  • Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
    ... Yes, and there's no reason we couldn't do the same on 64-bit, aside ... in large offsets, since they're always 32-bits anyway (there's no ... with GCC 4.2.0. ... I'm still re-verifying that the source bits and config options ...
    (Linux-Kernel)
  • offsets of stack variables with optimizations enabled in GCC
    ... I am trying to track the offsets of stack variables ... found lots of useful information on how to extract the offsets. ... use the offsets extracted from the GCC RTL. ... GDB debugger can't debug an optimized binary. ...
    (comp.unix.programmer)
  • Re: post 2.6.7 BK change breaks Java?
    ... > Nevermind, I should have looked more carefully. ... The offsets are fine in ... What version of GCC are you using? ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: packagemaker script assistance needed.
    ... Is there a reason you're conditionalizing the whole block instead of one ... the reason my program source code is so long. ... The programmatic interface will do all of what you want to. ... you have to fall back to gcc 3.3. ...
    (comp.sys.mac.programmer.help)