> > the problem with this is that x86 CISC instructions are inherently more
> > difficult to fix up runtime :(
>
> In what sense? I mean the linker is able to resolve it, so why should
> BTFIXUP not be able to do the same? [...]
>
> I think there are just few i386 relocation types, far less than on
> sparc.
> And BTFIXUP really works that way:
> on Intel, you'd
> #define PAGE_OFFSET (&__nonexistant_page_offset_object)
> then partially link the kernel (you'll get a bunch of undefined relocations
> to the __npoo). Then, you just record all the places where such undefined
> relocation happens, in the linker script define
> __nonexistant_page_offset_object to 0xC0000000 and link again.
on x86, we can do instructions like:
movl 0xc0000028(%eax), %ebx
the compiler expands it's patters wildly differently when it's a constant.
On Sparc you dont have this 'problem' because these immediate values are
quite limited. (well, it's RISC)
so the point behind having compile-time constants is to have:
movl 0xc0000028(%eax), %ebx
instead of:
movl __undefined, %ecx
movl (%ecx,%eax), %ebx
with is slower. Basically immediate values can be treated as a magic
one-time constant-value register, which gets filled out at prefetch time,
and costs basically nothing. (it's not completely free, it costs prefetch
bandwith and L1 space, but it's almost for free) If we go to external
variables we lose this (important) optimization. On Sparc you dont have
this problem because address-constants do not fit into immediate values,
so you have them explicitly loaded anyway. On x86 we even do some tricks
to get as much compile-time constants as possible, take a look at
asm-i386/fixmap.h, which changes otherwise runtime objects into 'constant
address' objects.
this is the main problem why i cant see how we could do the btfixup thing
into x86 without losing these optimizations. (and the compiler merges such
constant addresses with structure offsets, which makes a theoretical
immediate value linker even harder) but maybe it already exists?
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/