On Tue, 15 Apr 2003, David Mosberger wrote:
> >>>>> On Wed, 16 Apr 2003 00:43:06 -0500 (CDT), Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> said:
>
> Kai> You're right that 32 bits would be enough to hold the
> Kai> CRC. However, we do not yet know the checksum at compile time,
> Kai> so the trick I came up with is to use the linker to fill in the
> Kai> crcs afterwards, using assignment to absolute values. So while
> Kai> the crcs appear to be numbers to the C code, they are handled
> Kai> like addresses from the linker side, and things would most
> Kai> likely go badly wrong if the sizes aren't equal, though I have
> Kai> to admit I didn't try.
>
> Yes, it's not easy (possible) to do it in C, but I suspect most 64-bit
> assemblers/linkers can do it. For example, on ia64, you can do:
>
> .global foo
>
> data4 foo
>
> Which will yield a DIR32LSB relocation (32-bit direct value), which is
> exactly what we'd need here.
I looked at ppc64, since I have a cross-compile tool chain for that, it
seems to have an appropriate relocation type (R_PPC64_UADDR32), but the
obvious way of doing
static const u32 __kcrctab_##sym \
__attribute__((section("__kcrctab" sec), unused)) \
= (u32) &__crc_##sym;
and hoping for the compiler to generate appropriate assembler code doesn't
work ("initializer element is not computable at load time"), so we'd need
to code this in asm explicitly, which I'd rather avoid at this time.
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:18 EST