lkml.org 
[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: size of CRCs in module versions
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.053 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site