From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emagii.se (www.emagii.com [185.133.207.17]) by sourceware.org (Postfix) with ESMTPS id ED7123858425 for ; Wed, 8 Mar 2023 13:23:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED7123858425 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=emagii.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emagii.com Received: from [10.175.196.145] (84-55-68-216.customers.ownit.se [84.55.68.216]) by emagii.se (Postfix) with ESMTPSA id F01B51205C6; Wed, 8 Mar 2023 14:23:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1678281828; bh=Kua5kpn++uoGANO3KU84zHrG68UEdXKnz0on9NrrI98=; h=Subject:To:From; b=X+QxKI9Gv0cJ7RGpO4+qCsyrtYNb+CVMfkjL2oY4r7eajsngLI545BRM6HcUbNDmN pnnCE77Z4fthoy6qzDBe3Fkd3SZdhWhLf5HxMYg25pideItVqbFTYmlTGe/B8N5fsh RaoPaE2dTfZA0UdqNMKdNFPjROaa5al3OJBp+S7s= Authentication-Results: emagii.beebytevps.io; spf=pass (sender IP is 84.55.68.216) smtp.mailfrom=binutils@emagii.com smtp.helo=[10.175.196.145] Received-SPF: pass (emagii.beebytevps.io: connection is authenticated) Message-ID: Date: Wed, 8 Mar 2023 14:23:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v12 0/11 Add support for CRC64 generation in linker Content-Language: en-US To: Nick Clifton , =?UTF-8?Q?Martin_Li=c5=a1ka?= , binutils@sourceware.org, schwab@suse.de References: <20230306133158.91917-1-binutils@emagii.com> <22f15ceb-e5db-8fd8-94a2-57e87cea6574@emagii.com> <9e098af0-2aec-8570-ee5c-439c39738284@suse.cz> <9f8b7d8d-4058-315c-0469-e8853a4e1576@redhat.com> From: Ulf Samuelsson In-Reply-To: <9f8b7d8d-4058-315c-0469-e8853a4e1576@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <167828182847.2205320.15126198832792548832@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_FAIL,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > > >