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

[Ulf Samuelsson]

On 2023-03-08 13:52, Nick Clifton wrote:
> 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.

That can change, but that is of course a hassle.

>
>> 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.
>
I think you have to rewrite the expression evaluator to be 64-bit for 
this to work


>
>> 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.
>
Actually that is not true.

The width of the CRC is depending on the size of the area you are checking.
A larger area needs more bits.
A few kB of code are OK with a 32 bit CRC, but I think when you are
getting close to 100 kB, you should consider a 64-bit CRC.

I read about this quite some time ago, so I do not remembed the cut-off
point, but when you have 1 MByte of code, then CRC32 is not good enough.
I tried to find a statement on when to switch from 32-bit to 64-bit 
right now without success.

Texas Instruments certainly put a 64-bit H/W CRC in parts where you have 
4 MByte of flash.

In the CRC world you speak of "Hamming distance".
If I understand things correctly, that is basically the risk that you 
have two
similar images that generate the same checksum.
Another way of putting it is how many independent bit errors you can detect.

Best Regards

Ulf Samuelsson



> Cheers
>   Nick
>
>
>