From: Ulf Samuelsson <binutils@emagii.com>
To: binutils@sourceware.org
Cc: nickc@redhat.com, Ulf Samuelsson <ulf@emagii.com>
Subject: Re: [PATCH v6 02/11] DIGEST: NEWS
Date: Wed, 1 Mar 2023 15:57:28 +0100 [thread overview]
Message-ID: <16338158-d881-47e8-7628-75828da90138@emagii.com> (raw)
In-Reply-To: <20230301144756.1847278-3-binutils@emagii.com>
On 2023-03-01 15:47, Ulf Samuelsson via Binutils wrote:
> From: Ulf Samuelsson <ulf@emagii.com>
>
> Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
> ---
> ld/NEWS | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 76 insertions(+), 4 deletions(-)
>
> diff --git a/ld/NEWS b/ld/NEWS
> index 4b91f2c3b0a..e245d3da4dc 100644
> --- a/ld/NEWS
> +++ b/ld/NEWS
> @@ -1,5 +1,77 @@
> -*- text -*-
>
> +* The linker script has a new command to insert a timestamp
> + TIMESTAMP
> + inserts the current time (seconds since Epoch) as a 64-bit value
> +
> +* The linker script syntax has new commands for debugging a linker script
> + DEBUG ON turns on debugging
> + DEBUG OFF turns off debugging
> +
> +* The linker script syntax has new commands for handling CRC-32/64 calculations
> + on the '.text' section
> + It uses code from https://www.libcrc.org/
> +
> + DIGEST "<label>[.BE]" "CRC32" (start, end)
> + DIGEST "<label>[.BE]" "CRC64-ECMA" (start, end)
> + DIGEST "<label>[.BE]" "CRC64-GO-ISO" (start, end)
> + DIGEST "<label>[.BE]" "CRC64-GO-ISO-R" (start, end)
> + DIGEST "<label>[.BE]" "CRC64-WE" (start, end)
> + DIGEST "<label>[.BE]" "CRC64-XZ" (start, end)
> + DIGEST "<label>[.BE]" POLY (<params>) (start, end)
> + DIGEST TABLE "<label>[.BE]"
> + DIGEST SECTION "<section>"
> +
> + The CRC32, CRC64-ECMA, CRC64-ISO, CRC64-WE and POLY defines
> + the polynome to use and reserves space for the 32/64-bit CRC in the
> + current section (default ".text"). It also defines a label "<label>".
> +
> + When generating a custom polynome you have to supply parameters
> + in the following order
> + * size {32 | 64 }
> + * polynome
> + * initial initial value of crc
> + * xor value xor with this before returning result
> + * input reflect bitreverse input data
> + * output reflect bitreverse result
> + * reciprocal bitreverse polynome
> +
> + These terms are explained at
> + http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html
> +
> + The checksum is generated in little endian format, but this
> + can be overridden by adding a ".BE" modifier to the label string.
> + The generated label does not include the modifier.
> +
> + The user can do the CRC check in another section through the
> + DIGEST SECTION command by specifying the name of the section.
> +
> + The 32 bit DIGEST <polynome> command defines some global symbols.
> + ___CRC32___ is the address of the CRC64 checksum
> + ___CRC32_START___ is the address where CRC calculation starts
> + ___CRC32_END___ The CRC calculation ends before this address.
> +
> + The 64-bit DIGEST <polynome> command defines some global symbols.
> + ___CRC64___ is the address of the CRC64 checksum
> + ___CRC64_START___ is the address where CRC calculation starts
> + ___CRC64_END___ The CRC calculation ends before this address.
> +
> + All three symbols must refer to addresses in the selected section.
> + If they are defined at the end of the linking process, then
> + the CRC## will be calculated between
> +
> + ___CRC##_START___ .. ___CRC##_END___ -1
> +
> + and the result will be inserted at ___CRC##___.
> +
> + ___CRC##___ must be outside the region where CRC is calculated
> +
> + The DIGEST TABLE command generates a table for CRC generation.
> + A table is not neccessary, but will speed up the calculation.
> + It defines the ___CRC##_TABLE___ symbol at the start of the table.
> + The user may choose to add this table to his code instead of using
> + the linker.
> +
> * The linker script syntax has two new commands for inserting text into output
> sections:
> ASCII (<size>) "string"'
The stuff below was added unintentionally.
Do not know where is comes from...
Should have done a rebase before sending...
Best Regards
Ulf Samuelsson
> @@ -41,16 +113,16 @@ Changes in 2.39:
> re-enabled via the --warn-rwx-segments option.
>
> New configure options can also control these new features:
> -
> +
> --enable-warn-execstack=no
> will disable the warnings about creating an executable stack.
> -
> +
> --enable-warn-execstack=yes
> will make --warn-execstack enabled by default.
> -
> +
> --enable-warn-rwx-segments=no
> will make --no-warn-rwx-segments enabled by default.
> -
> +
> --enable-default-execstack=no
> will stop the creation of an executable stack simply because an input file
> is missing a .note.GNU-stack section, even on architectures where this
next prev parent reply other threads:[~2023-03-01 14:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 14:47 [PATCH v6 0/11 Add support for CRC64 generation in linker binutils
2023-03-01 14:47 ` [PATCH v6 01/11] DIGEST: LICENSING binutils
2023-03-01 15:04 ` Nick Clifton
2023-03-01 15:30 ` Ulf Samuelsson
2023-03-01 17:15 ` Nick Clifton
2023-03-01 17:19 ` Ian Lance Taylor
2023-03-01 14:47 ` [PATCH v6 02/11] DIGEST: NEWS binutils
2023-03-01 14:57 ` Ulf Samuelsson [this message]
2023-03-01 14:47 ` [PATCH v6 03/11] DIGEST: Documentation binutils
2023-03-01 14:47 ` [PATCH v6 04/11] DIGEST: testsuite binutils
2023-03-01 16:48 ` Nick Clifton
2023-03-01 17:33 ` Ulf Samuelsson
2023-03-01 14:47 ` [PATCH v6 05/11] DIGEST: ldlex.l binutils
2023-03-01 14:47 ` [PATCH v6 06/11] DIGEST: ldgram.y binutils
2023-03-01 14:47 ` [PATCH v6 07/11] DIGEST: ldmain.c binutils
2023-03-01 14:47 ` [PATCH v6 08/11] DIGEST: ldlang.*: add timestamp binutils
2023-03-01 14:47 ` [PATCH v6 09/11] DIGEST: calculation binutils
2023-03-01 14:47 ` [PATCH v6 10/11] DIGEST: Makefile.* binutils
2023-03-01 14:47 ` [PATCH v6 11/11] Build ldint binutils
2023-03-01 14:53 ` [PATCH v6 0/11 Add support for CRC64 generation in linker Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16338158-d881-47e8-7628-75828da90138@emagii.com \
--to=binutils@emagii.com \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
--cc=ulf@emagii.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).