Re: [PATCH v12 0/11 Add support for CRC64 generation in linker

[Nick Clifton <nickc@redhat.com>]

Hi Ulf,

>  From the error message, it looks like it it is 32-bit on 32-bit hosts, and 64-bit on 64-bit hosts.

Weel, it can be 64-bit on 32-bit hosts, provided that
   a) they support 64-bit arithmetic in the compiler
   b) the binutils are configured with --enable-64-bit-bfd

> TEMPORARY WORKAROUND:
> 
> There is (according to comments in bfd/bfd-in2.h) a workaround by
> configuring with "--enable-64-bit-bfd".
> 
> I do not know if that has any other side effects.
> 
> QUESTION: Can You guys, test "./configure --enable-64-bit-bfd" ?

Yes, and it does "fix" the problem, but ...

> QUESTION: What are the main drawbacks to this workaround?

Most 32-bit versions of the binutils are not built with --enable-64-bit-bfd
so there will still be an issue.

> Building using 32-bit bfd_vma makes life a lot more difficult since a lot of the code uses the bfd_vma type.

Actually not so much.  It is still safe to use the bfd_vma type for
addresses.  The only real change is to use uint64_t instead of bfd_vma
when talking about 64-bit crc values.


> So if you do DIGEST POLY (64,0xD800000000000000ULL,x,y,z,v,w)
> the expression calculator will return the wrong value for the all the 64 bit
> constants larger than 0xFFFFFFFF.
> 
> You  do not get around this, except by redesigning a **lot**.
> 
> CONCLUSION: I do not see a permanent fix that allows the DIGEST feature
> to work when building with a 32-bit BFD.

I am testing a local patch which solves (most of) the problem
by using uin64_t.  It does not resolve the arguments to the POLY
digest issue that you describe above, but instead it adds a note
to the documentation saying that the generation of 64-bit polynomes
is not supported when the host and target are both 32-bit.  My
assumption is that for this kind of host/target combination the
user is never going to want 64-bit polynomes anyway, so the
restriction should not be too bad.

Cheers
   Nick