[RFC v0 0/1] Add support for CRC64 generation in linker

[RFC v0 0/1] Add support for CRC64 generation in linker

[binutils]

Here is the first draft of introducing CRC64 generation in the linker

So far it
* reserves room for the CRC (8 bytes)
* Declares a symbol ___CRC64___ for the address of the CRC.
* Allows specifying the polynom (ECMA, ISO or your own)
* Allows for inversion in the CRC calculation (CRC64-WE)
* Allows specifying the area that should be checked.
* Declares the symbol "___CRC64_START__" for the beginning
* Declares the symbol "___CRC64_END__"   for the end (not included)
* Creates a 2kB table which speeds up the CRC calculation
* Can insert the 2kB table into the .text section

It does not yet calculate the CRC of the specified area.
I need to figure out how to access the section(s) covered
for calculating the CRC (between ___CRC64_START___ and ___CRC64_END___)
and then insert the calculated CRC at ___CRC64___ before
the output is generated.

[PATCH v0 1/1] [RFC] Add support for CRC64 generation in linker

[PATCH v0 1/1] [RFC] Add support for CRC64 generation in linker

[binutils]

From: Ulf Samuelsson <ulf@emagii.com>

Support the following new linker commands:
* CRC64 ECMA                     '(' crc_start ',' crc_end ')'
* CRC64 ISO                      '(' crc_start ',' crc_end ')'
* CRC64 POLY  '[' mustbe_exp ']' '(' crc_start ',' crc_end ')'
* CRC64 POLYI '[' mustbe_exp ']' '(' crc_start ',' crc_end ')'
* CRC64 TABLE

ECMA  == 0x42F0E1EBA9EA3693
ISO   == 0xD800000000000000
POLY  == Allows your own polynome
POLYI == Allows your own polynome, with inversion during calc

The CRC is calculated from crc_start to crc_end (not included)

The linker will define
'___CRC64___'   as the address of the CRC
'___CRC64_START__ as the first address to be CRC checked
'___CRC64_END___' as the first address after the CRC check block

* CRC TABLE creates a 2kB CRC table at the current location counter
  This is used to speed up the CRC calculation.

So far, this patchset prepares for calculation of CRC, but does not
actually do the comparision yet.

Comments on the code:
The ldgram.y duplicates a lot of code, and this could be done
in a better way.

The code is using the libcrc released under an MIT license found in
* https://www.libcrc.org/
* https://github.com/lammertb/libcrc/tree/v2.0
Author:  Lammert Bies

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
---
 COPYING.CRC64                 |  43 ++++
 ld/checksum.h                 |  48 +++++
 ld/ldgram.y                   |  50 +++++
 ld/ldlang.c                   | 131 ++++++++++++
 ld/ldlang.h                   |   6 +
 ld/ldlex.l                    |   9 +
 ld/testsuite/ld-scripts/crc.d | 379 ++++++++++++++++++++++++++++++++++
 ld/testsuite/ld-scripts/crc.s |   9 +
 ld/testsuite/ld-scripts/crc.t |  39 ++++
 9 files changed, 714 insertions(+)
 create mode 100755 COPYING.CRC64
 create mode 100755 ld/checksum.h
 create mode 100644 ld/testsuite/ld-scripts/crc.d
 create mode 100644 ld/testsuite/ld-scripts/crc.s
 create mode 100644 ld/testsuite/ld-scripts/crc.t

diff --git a/COPYING.CRC64 b/COPYING.CRC64
new file mode 100755
index 00000000000..0034ba311fc
--- /dev/null
+++ b/COPYING.CRC64
@@ -0,0 +1,43 @@
+The GNU linker contains CRC routines that are used to implement the
+CRC16 command in the output section.
+
+The CRC routines are extracted from LIBCRC available at 
+
+They are used to 
+* https://www.libcrc.org/
+* https://github.com/lammertb/libcrc/tree/v2.0
+
+
+/*
+ * Library: libcrc
+ * File:    src/crc64.c
+ * Author:  Lammert Bies
+ *
+ * This file is licensed under the MIT License as stated below
+ *
+ * Copyright (c) 2016 Lammert Bies
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * Description
+ * -----------
+ * The source file src/crc64.c contains the routines which are needed to
+ * calculate a 64 bit CRC value of a sequence of bytes.
+ */
+ 
diff --git a/ld/checksum.h b/ld/checksum.h
new file mode 100755
index 00000000000..49a2aedd04b
--- /dev/null
+++ b/ld/checksum.h
@@ -0,0 +1,48 @@
+/*
+ * Library: libcrc
+ * Author:  Lammert Bies
+ *
+ * This file is licensed under the MIT License as stated below
+ *
+ * Copyright (c) 2016 Lammert Bies
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#ifndef CHECKSUM_H
+#define CHECKSUM_H
+
+#include <stddef.h>
+#include <stdint.h>
+
+#define		CRC_POLY_64			0x42F0E1EBA9EA3693ull
+#define		CRC_POLY_64_ISO		0xD800000000000000ull
+
+#define		CRC_START_64		0x0000000000000000ull
+#define		CRC_START_64_INV	0xFFFFFFFFFFFFFFFFull
+
+#define	CRC_ADDRESS	"___CRC64___"
+#define	CRC_START	"___CRC64_START___"
+#define	CRC_END		"___CRC64_END___"
+
+bfd_vma	crc_64    (const unsigned char *input_str, size_t num_bytes);
+bfd_vma	crc_64_inv(const unsigned char *input_str, size_t num_bytes);
+
+#endif /* CHECKSUM_H */
diff --git a/ld/ldgram.y b/ld/ldgram.y
index 8240cf97327..710de81ce71 100644
--- a/ld/ldgram.y
+++ b/ld/ldgram.y
@@ -41,6 +41,7 @@
 #include "mri.h"
 #include "ldctor.h"
 #include "ldlex.h"
+#include "checksum.h"
 
 #ifndef YYDEBUG
 #define YYDEBUG 1
@@ -130,6 +131,8 @@ static int error_index;
 %token DATA_SEGMENT_ALIGN DATA_SEGMENT_RELRO_END DATA_SEGMENT_END
 %token SORT_BY_NAME SORT_BY_ALIGNMENT SORT_NONE
 %token SORT_BY_INIT_PRIORITY
+%token CRC64 ECMA ISO POLY POLYI TABLE
+%token DEBUG ON OFF
 %token '{' '}'
 %token SIZEOF_HEADERS OUTPUT_FORMAT FORCE_COMMON_ALLOCATION OUTPUT_ARCH
 %token INHIBIT_COMMON_ALLOCATION FORCE_GROUP_ALLOCATION
@@ -676,6 +679,53 @@ statement:
 		{
 		  lang_add_fill ($3);
 		}
+	| DEBUG ON
+		{
+			yydebug = 1;
+		}
+	| DEBUG OFF
+		{
+			yydebug = 0;
+		}
+
+	| CRC64 ECMA '(' mustbe_exp ',' mustbe_exp ')'
+		{
+		  etree_type *DOT = exp_nameop (NAME,".");
+		  lang_add_assignment (exp_assign (CRC_ADDRESS, DOT, false));
+		  lang_add_crc_syndrome(false, CRC_POLY_64);
+		  lang_add_assignment (exp_assign (CRC_START, $4, false));
+		  lang_add_assignment (exp_assign (CRC_END,   $6, false));
+		}
+	| CRC64 ISO '(' mustbe_exp ',' mustbe_exp ')'
+		{
+		  etree_type *DOT = exp_nameop (NAME,".");
+		  lang_add_assignment (exp_assign (CRC_ADDRESS, DOT, false));
+		  lang_add_crc_syndrome(false, CRC_POLY_64_ISO);
+		  lang_add_assignment (exp_assign (CRC_START, $4, false));
+		  lang_add_assignment (exp_assign (CRC_END,   $6, false));
+		}
+	| CRC64 POLY '[' mustbe_exp ']'  '(' mustbe_exp ',' mustbe_exp ')'
+		{
+		  etree_type *DOT = exp_nameop (NAME,".");
+		  lang_add_assignment (exp_assign (CRC_ADDRESS, DOT, false));
+		  etree_type *value = $4;
+		  lang_add_crc_syndrome(false, value->value.value);
+		  lang_add_assignment (exp_assign (CRC_START, $7, false));
+		  lang_add_assignment (exp_assign (CRC_END,   $9, false));
+		}
+	| CRC64 POLYI '[' mustbe_exp ']'  '(' mustbe_exp ',' mustbe_exp ')'
+		{
+		  etree_type *DOT = exp_nameop (NAME,".");
+		  lang_add_assignment (exp_assign (CRC_ADDRESS, DOT, false));
+		  etree_type *value = $4;
+		  lang_add_crc_syndrome(true, value->value.value);
+		  lang_add_assignment (exp_assign (CRC_START, $7, false));
+		  lang_add_assignment (exp_assign (CRC_END,   $9, false));
+		}
+	| CRC64 TABLE
+		{
+			lang_add_crc_table();
+		}
 	| ASSERT_K
 		{ ldlex_expression (); }
 	  '(' exp ',' NAME ')' separator
diff --git a/ld/ldlang.c b/ld/ldlang.c
index b20455c9373..3ba467d6202 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -42,6 +42,8 @@
 #include "demangle.h"
 #include "hashtab.h"
 #include "elf-bfd.h"
+#include "checksum.h"
+
 #if BFD_SUPPORTS_PLUGINS
 #include "plugin.h"
 #endif /* BFD_SUPPORTS_PLUGINS */
@@ -145,6 +147,11 @@ int lang_statement_iteration = 0;
 /* Count times through one_lang_size_sections_pass after mark phase.  */
 static int lang_sizing_iteration = 0;
 
+/* CRC calculation on output section */
+bfd_vma  crc64_poly  = CRC_POLY_64;	/* Default Polynome is CRC64 ECMA */
+bfd_vma *crc64_tab   = NULL;
+bool      crc64_invert= false;
+
 /* Return TRUE if the PATTERN argument is a wildcard pattern.
    Although backslashes are treated specially if a pattern contains
    wildcards, we do not consider the mere presence of a backslash to
@@ -8487,6 +8494,130 @@ lang_add_attribute (enum statement_enum attribute)
   new_statement (attribute, sizeof (lang_statement_header_type), stat_ptr);
 }
 
+/*
+ * bfd_vma *init_crc64_tab( bfd_vma poly ) ;
+ *
+ * For optimal speed, the CRC64 calculation uses a table with pre-calculated
+ * bit patterns which are used in the XOR operations in the program. This table
+ * is generated on request and is available as a table with constant values.
+ * init_crc64_tab is copyright (c) 2016 Lammert Bies 
+ */
+static
+bfd_vma *init_crc64_tab( bfd_vma poly ) {
+
+	bfd_vma i;
+	bfd_vma j;
+	bfd_vma c;
+	bfd_vma crc;
+	bfd_vma *crc_tab;
+	
+	crc_tab = malloc(256 * sizeof(bfd_vma));
+	if (crc_tab == NULL)
+		return NULL;
+
+	for (i=0; i<256; i++) {
+
+		crc = 0;
+		c   = i << 56;
+
+		for (j=0; j<8; j++) {
+
+			if ( ( crc ^ c ) & 0x8000000000000000ull ) crc = ( crc << 1 ) ^ poly;
+			else                                       crc =   crc << 1;
+
+			c = c << 1;
+		}
+
+		crc_tab[i] = crc;
+	}
+	return crc_tab;
+
+}  /* init_crc64_tab */
+
+/*
+ * bfd_vma crc_64_ecma( const unsigned char *input_str, size_t num_bytes );
+ *
+ * The function crc_64() calculates in one pass the 64 bit CRC value
+ * for a byte string that is passed to the function together with a parameter
+ * indicating the length.
+ * This is used for CRC64-ECMA and CRC64-ISO
+ * crc_64 is copyright (c) 2016 Lammert Bies
+ */
+
+bfd_vma crc_64(const unsigned char *input_str, size_t num_bytes)
+{
+	bfd_vma crc;
+	const unsigned char *ptr;
+	size_t a;
+	crc = CRC_START_64;
+	ptr = input_str;
+	if ( ptr != NULL ) {
+		for (a=0; a<num_bytes; a++) {
+			crc = (crc << 8) ^ crc64_tab[ ((crc >> 56) ^ (bfd_vma) *ptr++) & 0x00000000000000FFull ];
+		}
+	}
+	return crc;
+}  /* crc_64 */
+
+/*
+ * The function crc_64_inv() calculates in one pass the CRC64 64 bit CRC
+ * value for a byte string that is passed to the function together with a
+ * parameter indicating the length.
+ * This is used for CRC64-WE
+ * crc_64_inv is copyright (c) 2016 Lammert Bies
+ */
+
+bfd_vma crc_64_inv( const unsigned char *input_str, size_t num_bytes ) {
+
+	bfd_vma crc;
+	const unsigned char *ptr;
+	size_t a;
+
+	crc = CRC_START_64_INV;
+	ptr = input_str;
+
+	if ( ptr != NULL ) {
+		for (a=0; a<num_bytes; a++) {
+			crc = (crc << 8) ^ crc64_tab[ ((crc >> 56) ^ (bfd_vma) *ptr++) & 0x00000000000000FFull ];
+		}
+	}
+
+	return crc ^ 0xFFFFFFFFFFFFFFFFull;
+
+}  /* crc_64_inv */
+
+extern void lang_add_crc_syndrome(bool invert, bfd_vma poly)
+{
+  crc64_poly = poly;			/* Set the polynom */
+  crc64_invert = invert;
+  lang_add_data (QUAD, exp_intop (0));	/* Reserve room for the ECC value */
+  if (crc64_tab == NULL)
+    {
+      crc64_tab = init_crc64_tab(crc64_poly);
+    }
+  else
+    {
+      einfo (_("%P:%pS: warning: CRC polynome declared twice (ignored)\n"), NULL);
+    }
+}
+
+extern void lang_add_crc_table(void)
+{
+  if (crc64_tab == NULL)
+    {
+      crc64_tab = init_crc64_tab(crc64_poly);
+      if (crc64_tab == NULL)
+	{
+	  einfo (_("%F%P: can not allocate memory for CRC table: %E\n"));
+	  return;
+	}
+    }
+  for (bfd_vma i = 0 ; i < 256 ; i++)
+    {
+       lang_add_data (QUAD, exp_intop (crc64_tab[i]));
+    }
+}
+
 void
 lang_startup (const char *name)
 {
diff --git a/ld/ldlang.h b/ld/ldlang.h
index 32819066b8a..dd8fe29249b 100644
--- a/ld/ldlang.h
+++ b/ld/ldlang.h
@@ -632,6 +632,12 @@ extern lang_output_section_statement_type *lang_output_section_statement_lookup
   (const char *, int, int);
 extern lang_output_section_statement_type *next_matching_output_section_statement
   (lang_output_section_statement_type *, int);
+extern void lang_add_crc_syndrome
+  (bool, bfd_vma);
+extern void lang_add_crc_table
+  (void);
+extern void lang_set_crc_region
+  (union etree_union *start, union etree_union *end);
 extern void ldlang_add_undef
   (const char *const, bool);
 extern void ldlang_add_require_defined
diff --git a/ld/ldlex.l b/ld/ldlex.l
index 32336cf0be2..e872ce7b2c6 100644
--- a/ld/ldlex.l
+++ b/ld/ldlex.l
@@ -298,6 +298,15 @@ V_IDENTIFIER [*?.$_a-zA-Z\[\]\-\!\^\\]([*?.$_a-zA-Z0-9\[\]\-\!\^\\]|::)*
 <SCRIPT>"AFTER"				{ RTOKEN(AFTER); }
 <SCRIPT>"BEFORE"			{ RTOKEN(BEFORE); }
 <WILD>"FILL"				{ RTOKEN(FILL); }
+<WILD>"CRC64"				{ RTOKEN(CRC64); }
+<WILD>"ECMA"				{ RTOKEN(ECMA); }
+<WILD>"ISO"					{ RTOKEN(ISO); }
+<WILD>"POLY"				{ RTOKEN(POLY); }
+<WILD>"POLYI"				{ RTOKEN(POLYI); }
+<WILD>"TABLE"				{ RTOKEN(TABLE); }
+<WILD>"DEBUG"				{ RTOKEN(DEBUG); }
+<WILD>"ON"					{ RTOKEN(ON); }
+<WILD>"OFF"					{ RTOKEN(OFF); }
 <SCRIPT>"STARTUP"			{ RTOKEN(STARTUP); }
 <SCRIPT>"OUTPUT_FORMAT"			{ RTOKEN(OUTPUT_FORMAT); }
 <SCRIPT>"OUTPUT_ARCH"			{ RTOKEN(OUTPUT_ARCH); }
diff --git a/ld/testsuite/ld-scripts/crc.d b/ld/testsuite/ld-scripts/crc.d
new file mode 100644
index 00000000000..6f542cac747
--- /dev/null
+++ b/ld/testsuite/ld-scripts/crc.d
@@ -0,0 +1,379 @@
+#source: crc.s
+#ld: -T crc.t
+#objdump: -s -j .text
+#notarget: [is_aout_format]
+#xfail: tic4x-*-* tic54x-*-*
+
+.*:     file format .*
+
+Contents of section .text:
+ 1100 434f4445 deadbeef 00000000 00000000  CODE............
+ 1110 10110000 00000000 10280000 00000000  .........(......
+ 1120 00170000 00000000 deadbeef 434f4445  ............CODE
+ 1130 434f4445 10110000 ffffffff ffffffff  CODE............
+ 1140 ffffffff ffffffff ffffffff ffffffff  ................
+ 1150 ffffffff ffffffff ffffffff ffffffff  ................
+ 1160 ffffffff ffffffff ffffffff ffffffff  ................
+ 1170 ffffffff ffffffff ffffffff ffffffff  ................
+ 1180 ffffffff ffffffff ffffffff ffffffff  ................
+ 1190 ffffffff ffffffff ffffffff ffffffff  ................
+ 11a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 11b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 11c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 11d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 11e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 11f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1200 01ffffff ffffffff ffffffff ffffffff  ................
+ 1210 ffffffff ffffffff ffffffff ffffffff  ................
+ 1220 ffffffff ffffffff ffffffff ffffffff  ................
+ 1230 ffffffff ffffffff ffffffff ffffffff  ................
+ 1240 ffffffff ffffffff ffffffff ffffffff  ................
+ 1250 ffffffff ffffffff ffffffff ffffffff  ................
+ 1260 ffffffff ffffffff ffffffff ffffffff  ................
+ 1270 ffffffff ffffffff ffffffff ffffffff  ................
+ 1280 ffffffff ffffffff ffffffff ffffffff  ................
+ 1290 ffffffff ffffffff ffffffff ffffffff  ................
+ 12a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 12b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 12c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 12d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 12e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 12f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1300 ffffffff ffffffff ffffffff ffffffff  ................
+ 1310 ffffffff ffffffff ffffffff ffffffff  ................
+ 1320 ffffffff ffffffff ffffffff ffffffff  ................
+ 1330 ffffffff ffffffff ffffffff ffffffff  ................
+ 1340 ffffffff ffffffff ffffffff ffffffff  ................
+ 1350 ffffffff ffffffff ffffffff ffffffff  ................
+ 1360 ffffffff ffffffff ffffffff ffffffff  ................
+ 1370 ffffffff ffffffff ffffffff ffffffff  ................
+ 1380 ffffffff ffffffff ffffffff ffffffff  ................
+ 1390 ffffffff ffffffff ffffffff ffffffff  ................
+ 13a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 13b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 13c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 13d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 13e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 13f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1400 ffffffff ffffffff ffffffff ffffffff  ................
+ 1410 ffffffff ffffffff ffffffff ffffffff  ................
+ 1420 ffffffff ffffffff ffffffff ffffffff  ................
+ 1430 ffffffff ffffffff ffffffff ffffffff  ................
+ 1440 ffffffff ffffffff ffffffff ffffffff  ................
+ 1450 ffffffff ffffffff ffffffff ffffffff  ................
+ 1460 ffffffff ffffffff ffffffff ffffffff  ................
+ 1470 ffffffff ffffffff ffffffff ffffffff  ................
+ 1480 ffffffff ffffffff ffffffff ffffffff  ................
+ 1490 ffffffff ffffffff ffffffff ffffffff  ................
+ 14a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 14b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 14c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 14d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 14e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 14f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1500 ffffffff ffffffff ffffffff ffffffff  ................
+ 1510 ffffffff ffffffff ffffffff ffffffff  ................
+ 1520 ffffffff ffffffff ffffffff ffffffff  ................
+ 1530 ffffffff ffffffff ffffffff ffffffff  ................
+ 1540 ffffffff ffffffff ffffffff ffffffff  ................
+ 1550 ffffffff ffffffff ffffffff ffffffff  ................
+ 1560 ffffffff ffffffff ffffffff ffffffff  ................
+ 1570 ffffffff ffffffff ffffffff ffffffff  ................
+ 1580 ffffffff ffffffff ffffffff ffffffff  ................
+ 1590 ffffffff ffffffff ffffffff ffffffff  ................
+ 15a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 15b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 15c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 15d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 15e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 15f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1600 ffffffff ffffffff ffffffff ffffffff  ................
+ 1610 ffffffff ffffffff ffffffff ffffffff  ................
+ 1620 ffffffff ffffffff ffffffff ffffffff  ................
+ 1630 ffffffff ffffffff ffffffff ffffffff  ................
+ 1640 ffffffff ffffffff ffffffff ffffffff  ................
+ 1650 ffffffff ffffffff ffffffff ffffffff  ................
+ 1660 ffffffff ffffffff ffffffff ffffffff  ................
+ 1670 ffffffff ffffffff ffffffff ffffffff  ................
+ 1680 ffffffff ffffffff ffffffff ffffffff  ................
+ 1690 ffffffff ffffffff ffffffff ffffffff  ................
+ 16a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 16b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 16c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 16d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 16e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 16f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1700 ffffffff ffffffff ffffffff ffffffff  ................
+ 1710 ffffffff ffffffff ffffffff ffffffff  ................
+ 1720 ffffffff ffffffff ffffffff ffffffff  ................
+ 1730 ffffffff ffffffff ffffffff ffffffff  ................
+ 1740 ffffffff ffffffff ffffffff ffffffff  ................
+ 1750 ffffffff ffffffff ffffffff ffffffff  ................
+ 1760 ffffffff ffffffff ffffffff ffffffff  ................
+ 1770 ffffffff ffffffff ffffffff ffffffff  ................
+ 1780 ffffffff ffffffff ffffffff ffffffff  ................
+ 1790 ffffffff ffffffff ffffffff ffffffff  ................
+ 17a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 17b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 17c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 17d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 17e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 17f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1800 ffffffff ffffffff ffffffff ffffffff  ................
+ 1810 ffffffff ffffffff ffffffff ffffffff  ................
+ 1820 ffffffff ffffffff ffffffff ffffffff  ................
+ 1830 ffffffff ffffffff ffffffff ffffffff  ................
+ 1840 ffffffff ffffffff ffffffff ffffffff  ................
+ 1850 ffffffff ffffffff ffffffff ffffffff  ................
+ 1860 ffffffff ffffffff ffffffff ffffffff  ................
+ 1870 ffffffff ffffffff ffffffff ffffffff  ................
+ 1880 ffffffff ffffffff ffffffff ffffffff  ................
+ 1890 ffffffff ffffffff ffffffff ffffffff  ................
+ 18a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 18b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 18c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 18d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 18e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 18f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1900 ffffffff ffffffff ffffffff ffffffff  ................
+ 1910 ffffffff ffffffff ffffffff ffffffff  ................
+ 1920 ffffffff ffffffff ffffffff ffffffff  ................
+ 1930 ffffffff ffffffff ffffffff ffffffff  ................
+ 1940 ffffffff ffffffff ffffffff ffffffff  ................
+ 1950 ffffffff ffffffff ffffffff ffffffff  ................
+ 1960 ffffffff ffffffff ffffffff ffffffff  ................
+ 1970 ffffffff ffffffff ffffffff ffffffff  ................
+ 1980 ffffffff ffffffff ffffffff ffffffff  ................
+ 1990 ffffffff ffffffff ffffffff ffffffff  ................
+ 19a0 ffffffff ffffffff ffffffff ffffffff  ................
+ 19b0 ffffffff ffffffff ffffffff ffffffff  ................
+ 19c0 ffffffff ffffffff ffffffff ffffffff  ................
+ 19d0 ffffffff ffffffff ffffffff ffffffff  ................
+ 19e0 ffffffff ffffffff ffffffff ffffffff  ................
+ 19f0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1a90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1aa0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ab0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ac0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ad0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ae0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1af0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1b90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ba0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1bb0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1bc0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1bd0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1be0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1bf0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1c90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ca0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1cb0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1cc0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1cd0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ce0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1cf0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1d90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1da0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1db0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1dc0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1dd0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1de0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1df0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1e90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ea0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1eb0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ec0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ed0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ee0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ef0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f00 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f10 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f20 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f30 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f40 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f50 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f60 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f70 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f80 ffffffff ffffffff ffffffff ffffffff  ................
+ 1f90 ffffffff ffffffff ffffffff ffffffff  ................
+ 1fa0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1fb0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1fc0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1fd0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1fe0 ffffffff ffffffff ffffffff ffffffff  ................
+ 1ff0 ffffffff ffffffff 434f4445 deadbeef  ........CODE....
+ 2000 00000000 00000000 9336eaa9 ebe1f042  .........6.....B
+ 2010 266dd453 d7c3e185 b55b3efa 3c2211c7  &m.S.....[>.<"..
+ 2020 dfec420e 45663349 4cdaa8a7 ae87c30b  ..B.Ef3IL.......
+ 2030 f981965d 92a5d2cc 6ab77cf4 7944228e  ...]....j.|.yD".
+ 2040 bed9851c 8acc6692 2def6fb5 612d96d0  ......f.-.o.a-..
+ 2050 98b4514f 5d0f8717 0b82bbe6 b6ee7755  ..QO].........wU
+ 2060 6135c712 cfaa55db f2032dbb 244ba599  a5....U...-.$K..
+ 2070 47581341 1869b45e d46ef9e8 f388441c  GX.A.i.^.n....D.
+ 2080 ef85e190 ff783d66 7cb30b39 1499cd24  .....x=f|..9...$
+ 2090 c9e835c3 28bbdce3 5adedf6a c35a2ca1  ..5.(...Z..j.Z,.
+ 20a0 3069a39e ba1e0e2f a35f4937 51fffe6d  0i...../._I7Q..m
+ 20b0 160477cd 6dddefaa 85329d64 863c1fe8  ..w.m....2.d.<..
+ 20c0 515c648c 75b45bf4 c26a8e25 9e55abb6  Q\d.u.[..j.%.U..
+ 20d0 7731b0df a277ba71 e4075a76 49964a33  w1...w.q..ZvI.J3
+ 20e0 8eb02682 30d268bd 1d86cc2b db3398ff  ..&.0.h....+.3..
+ 20f0 a8ddf2d1 e7118938 3beb1878 0cf0797a  .......8;..x..yz
+ 2100 de0bc321 fff17acc 4d3d2988 14108a8e  ...!..z.M=).....
+ 2110 f8661772 28329b49 6b50fddb c3d36b0b  .f.r(2.IkP....k.
+ 2120 01e7812f ba974985 92d16b86 5176b9c7  .../..I...k.Qv..
+ 2130 278a557c 6d54a800 b4bcbfd5 86b55842  '.U|mT........XB
+ 2140 60d2463d 753d1c5e f3e4ac94 9edcec1c  `.F=u=.^........
+ 2150 46bf926e a2fefddb d58978c7 491f0d99  F..n......x.I...
+ 2160 bf3e0433 305b2f17 2c08ee9a dbbadf55  .>.30[/.,......U
+ 2170 9953d060 e798ce92 0a653ac9 0c793ed0  .S.`.....e:..y>.
+ 2180 318e22b1 008947aa a2b8c818 eb68b7e8  1."...G......h..
+ 2190 17e3f6e2 d74aa62f 84d51c4b 3cab566d  .....J./...K<.Vm
+ 21a0 ee6260bf 45ef74e3 7d548a16 ae0e84a1  .b`.E.t.}T......
+ 21b0 c80fb4ec 922c9566 5b395e45 79cd6524  .....,.f[9^Ey.e$
+ 21c0 8f57a7ad 8a452138 1c614d04 61a4d17a  .W...E!8.aM.a..z
+ 21d0 a93a73fe 5d86c0bd 3a0c9957 b66730ff  .:s.]...:..W.g0.
+ 21e0 50bbe5a3 cf231271 c38d0f0a 24c2e233  P....#.q....$..3
+ 21f0 76d631f0 18e0f3f4 e5e0db59 f30103b6  v.1........Y....
+ 2200 2f216cea 150205da bc178643 fee3f598  /!l........C....
+ 2210 094cb8b9 c2c1e45f 9a7a5210 2920141d  .L....._.zR.) ..
+ 2220 f0cd2ee4 50643693 63fbc44d bb85c6d1  ....Pd6.c..M....
+ 2230 d6a0fab7 87a7d716 4596101e 6c462754  ........E...lF'T
+ 2240 91f8e9f6 9fce6348 02ce035f 742f930a  ......cH..._t/..
+ 2250 b7953da5 480d82cd 24a3d70c a3ec728f  ..=.H...$.....r.
+ 2260 4e14abf8 daa85001 dd224151 3149a043  N.....P.."AQ1I.C
+ 2270 68797fab 0d6bb184 fb4f9502 e68a41c6  hy...k...O....A.
+ 2280 c0a48d7a ea7a38bc 539267d3 019bc8fe  ...z.z8.S.g.....
+ 2290 e6c95929 3db9d939 75ffb380 d658297b  ..Y)=..9u....X){
+ 22a0 1f48cf74 af1c0bf5 8c7e25dd 44fdfbb7  .H.t.....~%.D...
+ 22b0 39251b27 78dfea70 aa13f18e 933e1a32  9%.'x..p.....>.2
+ 22c0 7e7d0866 60b65e2e ed4be2cf 8b57ae6c  ~}.f`.^..K...W.l
+ 22d0 5810dc35 b775bfab cb26369c 5c944fe9  X..5.u...&6.\.O.
+ 22e0 a1914a68 25d06d67 32a7a0c1 ce319d25  ..Jh%.mg2....1.%
+ 22f0 87fc9e3b f2138ce2 14ca7492 19f27ca0  ...;......t...|.
+ 2300 f12aafcb eaf37f16 621c4562 01128f54  .*......b.Eb...T
+ 2310 d7477b98 3d309e93 44719131 d6d16ed1  .G{.=0..Dq.1..n.
+ 2320 2ec6edc5 af954c5f bdf0076c 4474bc1d  ......L_...lDt..
+ 2330 08ab3996 7856adda 9b9dd33f 93b75d98  ..9.xV.....?..].
+ 2340 4ff32ad7 603f1984 dcc5c07e 8bdee9c6  O.*.`?.....~....
+ 2350 699efe84 b7fcf801 faa8142d 5c1d0843  i..........-\..C
+ 2360 901f68d9 25592acd 03298270 ceb8da8f  ..h.%Y*..).p....
+ 2370 b672bc8a f29acb48 25445623 197b3b0a  .r.....H%DV#.{;.
+ 2380 1eaf4e5b 158b4270 8d99a4f2 fe6ab232  ..N[..Bp.....j.2
+ 2390 38c29a08 c248a3f5 abf470a1 29a953b7  8....H....p.).S.
+ 23a0 c1430c55 50ed7139 5275e6fc bb0c817b  .C.UP.q9Ru.....{
+ 23b0 e72ed806 872e90bc 741832af 6ccf60fe  ........t.2.l.`.
+ 23c0 a076cb47 9f4724e2 334021ee 74a6d4a0  .v.G.G$.3@!.t...
+ 23d0 861b1f14 4884c567 152df5bd a3653525  ....H..g.-...e5%
+ 23e0 7f9a8949 da2117ab ecac63e0 31c0e7e9  ...I.!....c.1...
+ 23f0 59f75d1a 0de2f62e cac1b7b3 e603066c  Y.]............l
+ 2400 cd74327d c0e5faf6 5e42d8d4 2b040ab4  .t2}....^B..+...
+ 2410 eb19e62e 17261b73 782f0c87 fcc7eb31  .....&.sx/.....1
+ 2420 12987073 8583c9bf 81ae9ada 6e6239fd  ..ps........nb9.
+ 2430 34f5a420 5240283a a7c34e89 b9a1d878  4.. R@(:..N....x
+ 2440 73adb761 4a299c64 e09b5dc8 a1c86c26  s..aJ).d..]...l&
+ 2450 55c06332 9dea7de1 c6f6899b 760b8da3  U.c2..}.....v...
+ 2460 ac41f56f 0f4faf2d 3f771fc6 e4ae5f6f  .A.o.O.-?w...._o
+ 2470 8a2c213c d88c4ea8 191acb95 336dbeea  .,!<..N.....3m..
+ 2480 22f1d3ed 3f9dc790 b1c73944 d47c37d2  "...?.....9D.|7.
+ 2490 049c07be e85e2615 97aaed17 03bfd657  .....^&........W
+ 24a0 fd1d91e3 7afbf4d9 6e2b7b4a 911a049b  ....z...n+{J....
+ 24b0 db7045b0 ad38155c 4846af19 46d9e51e  .pE..8.\HF..F...
+ 24c0 9c2856f1 b551a102 0f1ebc58 5eb05140  .(V..Q.....X^.Q@
+ 24d0 ba4582a2 62924087 2973680b 8973b0c5  .E..b.@.)sh..s..
+ 24e0 43c414ff f037924b d0f2fe56 1bd66209  C....7.K...V..b.
+ 24f0 65a9c0ac 27f473ce f69f2a05 cc15838c  e...'.s...*.....
+ 2500 137ff15c 3f14803a 80491bf5 d4f57078  ...\?..:.I....px
+ 2510 3512250f e8d761bf a624cfa6 033691fd  5.%...a..$...6..
+ 2520 cc93b352 7a72b373 5fa559fb 91934331  ...Rzr.s_.Y...C1
+ 2530 eafe6701 adb152f6 79c88da8 4650a2b4  ..g...R.y...FP..
+ 2540 ada67440 b5d8e6a8 3e909ee9 5e3916ea  ..t@....>...^9..
+ 2550 8bcba013 621b072d 18fd4aba 89faf76f  ....b..-..J....o
+ 2560 724a364e f0bed5e1 e17cdce7 1b5f25a3  rJ6N.....|..._%.
+ 2570 5427e21d 277d3464 c71108b4 cc9cc426  T'..'}4d.......&
+ 2580 fcfa10cc c06cbd5c 6fccfa65 2b8d4d1e  .....l.\o..e+.M.
+ 2590 da97c49f 17af5cd9 49a12e36 fc4eac9b  ......\.I..6.N..
+ 25a0 231652c2 850a8e15 b020b86b 6eeb7e57  #.R...... .kn.~W
+ 25b0 057b8691 52c96f90 964d6c38 b9289fd2  .{..R.o..Ml8.(..
+ 25c0 422395d0 4aa0dbce d1157f79 a1412b8c  B#..J......y.A+.
+ 25d0 644e4183 9d633a4b f778ab2a 7682ca09  dNA..c:K.x.*v...
+ 25e0 9dcfd7de 0fc6e887 0ef93d77 e42718c5  ..........=w.'..
+ 25f0 bba2038d d8050902 2894e924 33e4f940  ........(..$3..@
+ 2600 e2555e97 d5e7ff2c 7163b43e 3e060f6e  .U^....,qc.>>..n
+ 2610 c4388ac4 02241ea9 570e606d e9c5eeeb  .8...$..W.`m....
+ 2620 3db91c99 9081cc65 ae8ff630 7b603c27  =......e...0{`<'
+ 2630 1bd4c8ca 47422de0 88e22263 aca3dda2  ....GB-..."c....
+ 2640 5c8cdb8b 5f2b99be cfba3122 b4ca69fc  \..._+....1"..i.
+ 2650 7ae10fd8 88e8783b e9d7e571 63098879  z.....x;...qc..y
+ 2660 83609985 1a4daaf7 1056732c f1ac5ab5  .`...M...Vs,..Z.
+ 2670 a50d4dd6 cd8e4b72 363ba77f 266fbb30  ..M...Kr6;..&o.0
+ 2680 0dd0bf07 2a9fc24a 9ee655ae c17e3208  ....*..J..U..~2.
+ 2690 2bbd6b54 fd5c23cf b88b81fd 16bdd38d  +.kT.\#.........
+ 26a0 d23cfd09 6ff9f103 410a17a0 84180141  .<..o...A......A
+ 26b0 f451295a b83a1086 6767c3f3 53dbe0c4  .Q)Z.:..gg..S...
+ 26c0 b3093a1b a053a4d8 203fd0b2 4bb2549a  ..:..S.. ?..K.T.
+ 26d0 9564ee48 7790455d 065204e1 9c71b51f  .d.Hw.E].R...q..
+ 26e0 6ce57815 e5359791 ffd392bc 0ed467d3  l.x..5........g.
+ 26f0 4a88ac46 32f67614 d9be46ef d9178656  J..F2.v...F....V
+ 2700 3c5e9db6 2a1685e0 af68771f c1f775a2  <^..*....hw...u.
+ 2710 1a3349e5 fdd56465 8905a34c 16349427  .3I...de...L.4.'
+ 2720 e3b2dfb8 6f70b6a9 70843511 849146eb  ....op..p.5...F.
+ 2730 c5df0beb b8b3572c 56e9e142 5352a76e  ......W,V..BSR.n
+ 2740 828718aa a0dae372 11b1f203 4b3b1330  .......r....K;.0
+ 2750 a4eaccf9 771902f7 37dc2650 9cf8f2b5  ....w...7.&P....
+ 2760 5d6b5aa4 e5bcd03b ce5db00d 0e5d2079  ]kZ....;.]...] y
+ 2770 7b068ef7 327f31be e830645e d99ec1fc  {...2.1..0d^....
+ 2780 d3db7c26 d56eb886 40ed968f 3e8f48c4  ..|&.n..@...>.H.
+ 2790 f5b6a875 02ad5903 668042dc e94ca941  ...u..Y.f.B..L.A
+ 27a0 0c373e28 90088bcf 9f01d481 7be97b8d  .7>(........{.{.
+ 27b0 2a5aea7b 47cb6a4a b96c00d2 ac2a9a08  *Z.{G.jJ.l...*..
+ 27c0 6d02f93a 5fa2de14 fe341393 b4432e56  m..:_....4...C.V
+ 27d0 4b6f2d69 88613f91 d859c7c0 6380cfd3  Ko-i.a?..Y..c...
+ 27e0 b2eebb34 1ac4ed5d 21d8519d f1251d1f  ...4...]!.Q..%..
+ 27f0 94836f67 cd070cd8 07b585ce 26e6fc9a  ..og........&...
+ 2800 434f4445 deadbeef 00000000 00000000  CODE............
+#pass
diff --git a/ld/testsuite/ld-scripts/crc.s b/ld/testsuite/ld-scripts/crc.s
new file mode 100644
index 00000000000..704b492ae61
--- /dev/null
+++ b/ld/testsuite/ld-scripts/crc.s
@@ -0,0 +1,9 @@
+    .extern ecc_start
+	.section .text
+main:
+	.long 0x45444F43
+	.long ecc_start
+	.section .data
+	.long 0x9abcdef0
+	.section .bss
+	.long 0
diff --git a/ld/testsuite/ld-scripts/crc.t b/ld/testsuite/ld-scripts/crc.t
new file mode 100644
index 00000000000..eafc6f7a567
--- /dev/null
+++ b/ld/testsuite/ld-scripts/crc.t
@@ -0,0 +1,39 @@
+MEMORY {
+  rom : ORIGIN = 0x000000, LENGTH = 0x400000
+  ram : ORIGIN = 0x400000, LENGTH = 0x10000
+}
+
+_start = 0x000000;
+SECTIONS
+{
+  . = 0x1000 + SIZEOF_HEADERS;
+  .text ALIGN (0x100) :
+
+    {
+      FILL(0xFF)
+      QUAD(0xEFBEADDE45444F43);
+      crc64 = .;
+      CRC64 ECMA (ecc_start , ecc_end)
+      ecc_start = .;
+      QUAD(ecc_start)
+      QUAD(ecc_end);
+      QUAD(ecc_end - ecc_start);
+      QUAD(0x45444F43EFBEADDE);
+      entry = .;
+      *(.text)
+      . = ALIGN(0x100);
+      BYTE(1)
+      . = ALIGN(4096) - 8;
+      QUAD(0xEFBEADDE45444F43);
+      CRC64 TABLE
+      QUAD(0xEFBEADDE45444F43);
+      QUAD(0);
+      ecc_end = .;
+    } > rom
+
+  .data : AT (0x400000) { *(.data) } >ram /* NO default AT>rom */
+  . = ALIGN(0x20);
+  .bss : { *(.bss) } >ram /* NO default AT>rom */
+  /DISCARD/ : { *(*) }
+}
+
-- 
2.17.1

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson]

Den 2023-02-16 kl. 14:19, skrev Ulf Samuelsson via Binutils:
> Here is the first draft of introducing CRC64 generation in the linker
>
> So far it
> * reserves room for the CRC (8 bytes)
> * Declares a symbol ___CRC64___ for the address of the CRC.
> * Allows specifying the polynom (ECMA, ISO or your own)
> * Allows for inversion in the CRC calculation (CRC64-WE)
> * Allows specifying the area that should be checked.
> * Declares the symbol "___CRC64_START__" for the beginning
> * Declares the symbol "___CRC64_END__"   for the end (not included)
> * Creates a 2kB table which speeds up the CRC calculation
> * Can insert the 2kB table into the .text section
>
> It does not yet calculate the CRC of the specified area.
> I need to figure out how to access the section(s) covered
> for calculating the CRC (between ___CRC64_START___ and ___CRC64_END___)
> and then insert the calculated CRC at ___CRC64___ before
> the output is generated.
>
> [PATCH v0 1/1] [RFC] Add support for CRC64 generation in linker

Some of the formatting is off as well.

Best Regards
Ulf Samuelsson

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson]

On 2023-03-06 08:50, Fangrui Song wrote:
> On Fri, Feb 17, 2023 at 4:03 AM Ulf Samuelsson <binutils@emagii.com> wrote:
>>
>> Den 2023-02-17 kl. 12:11, skrev Nick Clifton:
>>> Hi Ulf,
>>>
>>>>> Hi Ulf, can you state why a built-in support of ld is needed? If you
>>>>> want to embed a checksum, you can use Output Section Data to reserve a
>>>>> few bytes in the output, then use a post-link tool to compute the
>>>>> checksum and rewrite the reserved bytes.
>>>> In my experience, the post link tools usually work on the binary data
>>>> and not the ELF file.
>>> The objcopy program can do most of this for you though.  For example:
>>>
>>>    % objcopy --dump-section .text=contents-of-text a.out
>>>    % crc32 contents-of-text > crc32-of-text
>>>    % objcopy --add-section .crc32=crc32-of-text a.out
>>>    % readelf -x.crc32 a.out
>>>    Hex dump of section '.crc32':
>>>      0x00000000 32323064 37636339 0a                220d7cc9.
>>>
>>> In this example the crc32 is stored as ascii text, but I am sure that
>>> you can find a version of the crc32 program that generates binary output.
>> The crc32 generates a 32-bit CRC. Modern microcontrollers require a
>> 64-bit CRC.
>>
>> The second problem is: where is the .crc32 section and its contents?
>> The program needs to access the contents, but it is already linked.
>> The typical use is a header in front of the program, and the header
>> is part of the ".text" area.
>> Can you explain how this would work?
>>
>>>
>>>> Another thing is that the post-link tools I have seen are typically
>>>> poorly maintained.
>>> ...and so you want to move that maintainership burden onto us, yes ?
>> The problem with the post-link tools is that they are hard wired to work on
>> special use cased.
>> Example of problems
>>
>> * CRC is fixed to be at a certain address
>>
>> * CRC table is fixed to be at a certain address.
>>
>> * Works on binaries and not on ELF files
>>
>> * You have to have one postprocessor for each file format.
> Hi Ulf, I think a natural question from other binutils contributors
> is: why is the CRC-64 feature so special that it deserves several
> keywords dedicated for it in the linker script language.
> You can place placeholder content into the CRC-64 section (say, it is
> .crc64), compute its value with a post-link program, then update the
> content with
> objcopy --update-section .crc64=.... exe

If you look at the latest patchset (v11),
you will find that there is no "CRC-64" keyword.
It is replaced by the "DIGEST" keyword which takes a string parameter
describing a "known" algorithm, or the POLY keyword
which allows you to specify your own algorithm.

If someone wants to support additional algorithms like the SHA series
it is esaily extended.

> If objcopy --update-section somehow doesn't achieve your goal, it may
> be worth a feature request or bug, since the operation is generic and
> useful for a large number of users, not just your CRC-64 customers.
The problems with supporting things in an external application
is that you need an application for every conceivable object file format.

The ielftools that I have used for this is 11-12000 lines of code of 
non-trivial code.

I do not not know just how many file format are supported but to me, it 
appears
to be at least a dozen.

There is no standard for such a tool, so you will find that many companies
need to maintain their own tool for this very purpose.

The next problem is that the "crc32" application is really only good for 
very
small microcontrollers with a few kB of flash. In order to support the 
128kB-MBs
of flash available in modern microcontrollers you need a 64 bit CRC.

There is no standard application that generates CRC-64.
That means someone needs to write an application that is allows standard
polynomes as well as custom polynomes.

Since the problem is difficult, many resort to just updating the binary,

which means that the code is not easily debuggable.
You cannot load the ELF file into the debugger and run, because it does
not have the checksum.

This patchset really allows people worldwide to get rid of millions
of lines of code that no longer is needed.

=====

The alternative I am proposing is straightforward code

The core code, doing the CRC calculation is well known.
The libcrc has not changed in 7 years.

>> None of these problems affect the linker since it is agnostic on the
>> file format
>> as long as there is a ".text" section.
>>
>> The CRC calculation has been stable on www.libcrc.com for 7 years.
>> There is no reason for the CRC calculation to change.
>> The only chance I can see is a different polynom, but that is already
>> supported.
>>
>> The biggest problem is of course that it slows down the debugging
>> because you cannot download from an ELF file - it lacks the CRC.
> I am unsure how a linker script extension is more convenient than
> using the existing functionality plus a CRC64 calculator and objcopy.
> The linker script extension appears to add a lot of code to the linker
> script language, which is already quite challenging to maintain.

It supports all object file formats and all architectures immediately.
It replaces millions of lines of code.

Your solution requires that the process knows which section contains the 
CRC.
If someone moves the CRC to a different section, your toolchain is broken.

The crc32 application computes the crc of all the .text section, so it 
cannot be used.
but you need to calculate the checsum of only part of the selected section.

You also need to insert the checksum at a user selectable part of the 
section.

On top of that, not having to postprocess the object code simplifies the 
flow.

So objcopy and crc32 does not meet the requirements as of today.

KEYWORDS.

Right now it adds the following keywords "DIGEST", "TABLE", "POLY".

In addition the patch has two more features.

* Debugging feature adding "DEBUG", "ON", "OFF"

* timestamp feature adding "TIMESTAMP"

> If you distribute such object files with CRC64, I don't think it harms
> debuggability.

There is no CRC64 application, and even if it was, it is a fragile solution,
because there is no automatic information on where to put the checksum
and what area to calculate the checksum on.

Adding checksum calculations to the linker is converting a very
difficult problem into a really simple one.

If you were managing a team to decide where to put the CRC calculation
the linker is the obvious place to look at.

Best Regards
Ulf Samuelsson

>
>>>
>>>> Adding a post-link step seems like a kludge if the linker can provide
>>>> the CRC inside the ELF file.
>>> But it also keeps things simple.  No new code in the linker = no new
>>> bugs in the linker.  Solving a problem using existing tools = no need
>>> for new versions of the linker when the already existing versions will
>>> work just fine.
>> The problem is that the existing versions *barely* work.
>> Every company have to write their own solution.
>> It does not support source level debugging.
>>
>> Supporting it in the linker makes for a much cleaner solution.
>>
>>> Cheers
>>>    Nick
>>>
>> Best Regards
>>
>> Ulf Samuelsson
>>
>>

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Fangrui Song]

On Fri, Feb 17, 2023 at 4:03 AM Ulf Samuelsson <binutils@emagii.com> wrote:
>
>
> Den 2023-02-17 kl. 12:11, skrev Nick Clifton:
> > Hi Ulf,
> >
> >>> Hi Ulf, can you state why a built-in support of ld is needed? If you
> >>> want to embed a checksum, you can use Output Section Data to reserve a
> >>> few bytes in the output, then use a post-link tool to compute the
> >>> checksum and rewrite the reserved bytes.
> >
> >> In my experience, the post link tools usually work on the binary data
> >> and not the ELF file.
> >
> > The objcopy program can do most of this for you though.  For example:
> >
> >   % objcopy --dump-section .text=contents-of-text a.out
> >   % crc32 contents-of-text > crc32-of-text
> >   % objcopy --add-section .crc32=crc32-of-text a.out
> >   % readelf -x.crc32 a.out
> >   Hex dump of section '.crc32':
> >     0x00000000 32323064 37636339 0a                220d7cc9.
> >
> > In this example the crc32 is stored as ascii text, but I am sure that
> > you can find a version of the crc32 program that generates binary output.
>
> The crc32 generates a 32-bit CRC. Modern microcontrollers require a
> 64-bit CRC.
>
> The second problem is: where is the .crc32 section and its contents?
> The program needs to access the contents, but it is already linked.
> The typical use is a header in front of the program, and the header
> is part of the ".text" area.
> Can you explain how this would work?
>
> >
> >
> >> Another thing is that the post-link tools I have seen are typically
> >> poorly maintained.
> >
> > ...and so you want to move that maintainership burden onto us, yes ?
>
> The problem with the post-link tools is that they are hard wired to work on
> special use cased.
> Example of problems
>
> * CRC is fixed to be at a certain address
>
> * CRC table is fixed to be at a certain address.
>
> * Works on binaries and not on ELF files
>
> * You have to have one postprocessor for each file format.

Hi Ulf, I think a natural question from other binutils contributors
is: why is the CRC-64 feature so special that it deserves several
keywords dedicated for it in the linker script language.
You can place placeholder content into the CRC-64 section (say, it is
.crc64), compute its value with a post-link program, then update the
content with
objcopy --update-section .crc64=.... exe

If objcopy --update-section somehow doesn't achieve your goal, it may
be worth a feature request or bug, since the operation is generic and
useful for a large number of users, not just your CRC-64 customers.

> None of these problems affect the linker since it is agnostic on the
> file format
> as long as there is a ".text" section.
>
> The CRC calculation has been stable on www.libcrc.com for 7 years.
> There is no reason for the CRC calculation to change.
> The only chance I can see is a different polynom, but that is already
> supported.
>
> The biggest problem is of course that it slows down the debugging
> because you cannot download from an ELF file - it lacks the CRC.

I am unsure how a linker script extension is more convenient than
using the existing functionality plus a CRC64 calculator and objcopy.
The linker script extension appears to add a lot of code to the linker
script language, which is already quite challenging to maintain.

If you distribute such object files with CRC64, I don't think it harms
debuggability.

> >
> >
> >> Adding a post-link step seems like a kludge if the linker can provide
> >> the CRC inside the ELF file.
> >
> > But it also keeps things simple.  No new code in the linker = no new
> > bugs in the linker.  Solving a problem using existing tools = no need
> > for new versions of the linker when the already existing versions will
> > work just fine.
>
> The problem is that the existing versions *barely* work.
> Every company have to write their own solution.
> It does not support source level debugging.
>
> Supporting it in the linker makes for a much cleaner solution.
>
> >
> > Cheers
> >   Nick
> >
> Best Regards
>
> Ulf Samuelsson
>
>

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson]

Den 2023-02-17 kl. 12:11, skrev Nick Clifton:
> Hi Ulf,
>
>>> Hi Ulf, can you state why a built-in support of ld is needed? If you
>>> want to embed a checksum, you can use Output Section Data to reserve a
>>> few bytes in the output, then use a post-link tool to compute the
>>> checksum and rewrite the reserved bytes.
>
>> In my experience, the post link tools usually work on the binary data 
>> and not the ELF file.
>
> The objcopy program can do most of this for you though.  For example:
>
>   % objcopy --dump-section .text=contents-of-text a.out
>   % crc32 contents-of-text > crc32-of-text
>   % objcopy --add-section .crc32=crc32-of-text a.out
>   % readelf -x.crc32 a.out
>   Hex dump of section '.crc32':
>     0x00000000 32323064 37636339 0a                220d7cc9.
>
> In this example the crc32 is stored as ascii text, but I am sure that
> you can find a version of the crc32 program that generates binary output.

The crc32 generates a 32-bit CRC. Modern microcontrollers require a 
64-bit CRC.

The second problem is: where is the .crc32 section and its contents?
The program needs to access the contents, but it is already linked.
The typical use is a header in front of the program, and the header
is part of the ".text" area.
Can you explain how this would work?

>
>
>> Another thing is that the post-link tools I have seen are typically 
>> poorly maintained.
>
> ...and so you want to move that maintainership burden onto us, yes ?

The problem with the post-link tools is that they are hard wired to work on
special use cased.
Example of problems

* CRC is fixed to be at a certain address

* CRC table is fixed to be at a certain address.

* Works on binaries and not on ELF files

* You have to have one postprocessor for each file format.

None of these problems affect the linker since it is agnostic on the 
file format
as long as there is a ".text" section.

The CRC calculation has been stable on www.libcrc.com for 7 years.
There is no reason for the CRC calculation to change.
The only chance I can see is a different polynom, but that is already 
supported.

The biggest problem is of course that it slows down the debugging
because you cannot download from an ELF file - it lacks the CRC.

>
>
>> Adding a post-link step seems like a kludge if the linker can provide 
>> the CRC inside the ELF file.
>
> But it also keeps things simple.  No new code in the linker = no new
> bugs in the linker.  Solving a problem using existing tools = no need
> for new versions of the linker when the already existing versions will
> work just fine.

The problem is that the existing versions *barely* work.
Every company have to write their own solution.
It does not support source level debugging.

Supporting it in the linker makes for a much cleaner solution.

>
> Cheers
>   Nick
>
Best Regards

Ulf Samuelsson

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Nick Clifton]

Hi Ulf,

>> Hi Ulf, can you state why a built-in support of ld is needed? If you
>> want to embed a checksum, you can use Output Section Data to reserve a
>> few bytes in the output, then use a post-link tool to compute the
>> checksum and rewrite the reserved bytes.

> In my experience, the post link tools usually work on the binary data and not the ELF file.

The objcopy program can do most of this for you though.  For example:

   % objcopy --dump-section .text=contents-of-text a.out
   % crc32 contents-of-text > crc32-of-text
   % objcopy --add-section .crc32=crc32-of-text a.out
   % readelf -x.crc32 a.out
   Hex dump of section '.crc32':
     0x00000000 32323064 37636339 0a                220d7cc9.

In this example the crc32 is stored as ascii text, but I am sure that
you can find a version of the crc32 program that generates binary output.


> Another thing is that the post-link tools I have seen are typically poorly maintained.

...and so you want to move that maintainership burden onto us, yes ?


> Adding a post-link step seems like a kludge if the linker can provide the CRC inside the ELF file.

But it also keeps things simple.  No new code in the linker = no new
bugs in the linker.  Solving a problem using existing tools = no need
for new versions of the linker when the already existing versions will
work just fine.

Cheers
   Nick

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Nick Clifton]

Hi Ulf,

> Before CRC:
> 0x00001100: 0xefbeadde45444f43 0x0000000000000000 0x0000000000000000 0x0000000000001118
> 
> *CRC [0xc79d3a1ef51fb737] update at 0x00001110 succeeded*
> 
> After CRC:
> 0x00001100: 0xefbeadde45444f43 0x0000000000000000 0xc79d3a1ef51fb737 0x0000000000001118

Sorry - I am a little confused here.  Does this mean that your v0
patch set is working ?  I was going to suggest that the reason that
calling bfd_get_section_contents() does not work, is that it is being
called too early - before the contents have actually been assigned.

I am also concerned that your patch includes copyrighted code that
appears to come without any license attached.  (Maybe it is in the
LICENSE file that you say you could not upload ?)

Also - from a flexibility point of view - wouldn't it be better if
the CRC were to be computed by an external program, rather than being
built into the linker ?  That way the user could decide exactly which
digest algorithm they wanted to use.  I am pretty sure that you can
arrange for the patch to fork/exec another program to compute the
CRC for you.

Cheers
   Nick

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Nick Clifton]

Hi Guys,

>> Cleaned up attempt to generate CRC64.

> I am asking because I am unsure whether this feature is generic enough
> to meet a majority of future users' needs. We can reasonably expect
> that other users may want to use different message digest
> algorithms...

I tend to agree with Fanguri here.  To me this seems like a situation where
using a linker plugin might be the way to go.  You could have different
plugins for different digest algorithms, and keeping the code separate from
the linker means that, if desired, the feature can be maintained and developed
without regard to the binutils release schedule.

Cheers
   Nick

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]


Den 2023-02-16 kl. 21:40, skrev Ulf Samuelsson via Binutils:
> Cleaned up attempt to generate CRC64.
>
>
> Added code in lang_end() to calculate the CRC.
> So far, I can retrieve the location of the CRC
> and the start and end for the area.
> I can fetch the .text segment as an asection but
>   
>    if ( bfd_get_section_contents (link_info.output_bfd,
> 	  ts,
> 	  text_section,
> 	  0,
> 	  ts->size))
>
> fails...
>
> The patchset should contain the LICENSE and the testsuite
> but git-send-email does not like if I send 8 patches.
> Sending 6 patches is OK for some reason...
>
> [PATCH v0 1/6] CRC64 header
> [PATCH v0 2/6] ldlang.h: CRC64
> [PATCH v0 3/6] ldlex.l: CRC64
> [PATCH v0 4/6] ldgram.y: CRC64
> [PATCH v0 5/6] ldlang.c: CRC64
> [PATCH v0 6/6] ldlang.c: Try to get the .text section for checking
>
gcc -c crc.s
../bin/bin/ld -T crc.t -o crc crc.o
Adding Syndrome: 0x42f0e1eba9ea3693
Adding Syndrome: 0xd800000000000000
../bin/bin/ld:crc.t:18: warning: CRC polynome declared twice (ignored)
.text: [0x00001100 .. 0x00002810]
bfd_malloc_and_get_section succeeded

Before CRC:
0x00001100: 0xefbeadde45444f43 0x0000000000000000 0x0000000000000000 
0x0000000000001118

*CRC [0xc79d3a1ef51fb737] update at 0x00001110 succeeded*

After CRC:
0x00001100: 0xefbeadde45444f43 0x0000000000000000 0xc79d3a1ef51fb737 
0x0000000000001118

Full Section After CRC:
0x00001100: 0xefbeadde45444f43 0x0000000000000000 0xc79d3a1ef51fb737 
0x0000000000001118
0x00001140: 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 
0xffffffffffffffff
0x00001180: 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 
0xffffffffffffffff
0x000011c0: 0xffffffffffffffff 0xffffffffffffffff 0xffffffffffffffff 
0xffffffffffffffff

:-)

Best Regards
Ulf Samuelsson

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Ulf Samuelsson]

Den 2023-02-16 kl. 22:30, skrev Fangrui Song:
> On Thu, Feb 16, 2023 at 12:40 PM Ulf Samuelsson via Binutils
> <binutils@sourceware.org> wrote:
>> Cleaned up attempt to generate CRC64.
>>
>>
>> Added code in lang_end() to calculate the CRC.
>> So far, I can retrieve the location of the CRC
>> and the start and end for the area.
>> I can fetch the .text segment as an asection but
>>
>>    if ( bfd_get_section_contents (link_info.output_bfd,
>>            ts,
>>            text_section,
>>            0,
>>            ts->size))
>>
>> fails...
>>
>> The patchset should contain the LICENSE and the testsuite
>> but git-send-email does not like if I send 8 patches.
>> Sending 6 patches is OK for some reason...
>>
>> [PATCH v0 1/6] CRC64 header
>> [PATCH v0 2/6] ldlang.h: CRC64
>> [PATCH v0 3/6] ldlex.l: CRC64
>> [PATCH v0 4/6] ldgram.y: CRC64
>> [PATCH v0 5/6] ldlang.c: CRC64
>> [PATCH v0 6/6] ldlang.c: Try to get the .text section for checking
>>
> Hi Ulf, can you state why a built-in support of ld is needed? If you
> want to embed a checksum, you can use Output Section Data to reserve a
> few bytes in the output, then use a post-link tool to compute the
> checksum and rewrite the reserved bytes.

Yes, this is what I have been doing so far, and I am not happy about it.

In my experience, the post link tools usually work on the binary data 
and not the ELF file.
The IAR ielftool that I ported is an exception, but it is not 100% 
compatible with the result of the GNU linker.

That means that you cannot load the ELF file into a debugger and run,
because you do not have the CRC in the ELF file, only in the 
binary/hex-file.

Another thing is that the post-link tools I have seen are typically 
poorly maintained.

Adding a post-link step seems like a kludge if the linker can provide 
the CRC inside the ELF file.

> I am asking because I am unsure whether this feature is generic enough
> to meet a majority of future users' needs. We can reasonably expect
> that other users may want to use different message digest
> algorithms...

The feature allows a CRC-64 to be generated using either ECMA, ISO or a 
user defined polynom.
This means that you cannot make a more generic CRC-64.

The only projects I can see that would need anything else are 8 bit 
micros with a few kB of flash.
They could use a CRC-32 and may trade off speed for code size using a 
non-table driven version.

Adding this functionality does not mean that a user have to use it.
They can continue to use a post-link tool to create CRC64 or any other CRC.
If they want something else, they can do that as well.

For those that do want CRC64, this simplifes things a lot.

> Cheers

Best Regards
Ulf Samuelsson

Re: [RFC v0 0/1] Add support for CRC64 generation in linker

[Fangrui Song]

On Thu, Feb 16, 2023 at 12:40 PM Ulf Samuelsson via Binutils
<binutils@sourceware.org> wrote:
>
> Cleaned up attempt to generate CRC64.
>
>
> Added code in lang_end() to calculate the CRC.
> So far, I can retrieve the location of the CRC
> and the start and end for the area.
> I can fetch the .text segment as an asection but
>
>   if ( bfd_get_section_contents (link_info.output_bfd,
>           ts,
>           text_section,
>           0,
>           ts->size))
>
> fails...
>
> The patchset should contain the LICENSE and the testsuite
> but git-send-email does not like if I send 8 patches.
> Sending 6 patches is OK for some reason...
>
> [PATCH v0 1/6] CRC64 header
> [PATCH v0 2/6] ldlang.h: CRC64
> [PATCH v0 3/6] ldlex.l: CRC64
> [PATCH v0 4/6] ldgram.y: CRC64
> [PATCH v0 5/6] ldlang.c: CRC64
> [PATCH v0 6/6] ldlang.c: Try to get the .text section for checking
>

Hi Ulf, can you state why a built-in support of ld is needed? If you
want to embed a checksum, you can use Output Section Data to reserve a
few bytes in the output, then use a post-link tool to compute the
checksum and rewrite the reserved bytes.

I am asking because I am unsure whether this feature is generic enough
to meet a majority of future users' needs. We can reasonably expect
that other users may want to use different message digest
algorithms...

Cheers

[RFC v0 0/1] Add support for CRC64 generation in linker

[binutils]

Cleaned up attempt to generate CRC64.


Added code in lang_end() to calculate the CRC.
So far, I can retrieve the location of the CRC
and the start and end for the area.
I can fetch the .text segment as an asection but
 
  if ( bfd_get_section_contents (link_info.output_bfd,
	  ts,
	  text_section,
	  0,
	  ts->size))

fails...

The patchset should contain the LICENSE and the testsuite
but git-send-email does not like if I send 8 patches.
Sending 6 patches is OK for some reason...

[PATCH v0 1/6] CRC64 header
[PATCH v0 2/6] ldlang.h: CRC64
[PATCH v0 3/6] ldlex.l: CRC64
[PATCH v0 4/6] ldgram.y: CRC64
[PATCH v0 5/6] ldlang.c: CRC64
[PATCH v0 6/6] ldlang.c: Try to get the .text section for checking