Recent Manual Updates for XLINK V4.59N

Updated: Jun 20, 2005 [IJYB]
Archived: $Revision: 1.52 $

This document is a supplement to the XLINK Release Notes, xlink.htm, and contains recent changes to the XLINK manual. Each section or sub-section is marked with the XLINK version of its most recent change. No attempt is made to represent a history of changes in this file. It documents only the current state of affairs.

If you are using XLINK in the Embedded Workbench integrated development environment, you may need a newer version of the Embedded Workbench for the relevant target in order to take full advantage of recently added features.

Added Output Formats

IEEE-695 Details

XCOFF78K Details

Checksums and Fillers (-H -J -h)

  • 4.51G - Filler Bytes

    The command line option "-H" can be used to generate filler bytes:

    Fill all linker-introduced gaps between segment parts with the repeated hexstring. The linker can introduce gaps because of alignment restrictions, or to fill ranges given in segment placement options. The normal behavior, when no -H option is given, is that these gaps are not given a value in the output file.

    The ranges that are filled are all the ranges into which segments with any content (code or constant data bytes) are placed. For a more explicit way to specify which ranges are filled, see the explanation of -h below.

    Example:

    Fill all the gaps with the value 0xbeef. Even bytes will get the value 0xbe, and odd bytes will get the value 0xef.
  • 4.51Q - Checksum Generation

    The command line option "-J" can be used to generate a checksum in the linker image:

    Checksum all generated raw data bytes.
        size can be one of:
            1       One byte of checksum
            2       Two bytes of checksum
            4       Four bytes of checksum
    
        algorithm can be one of:
            sum     Simple arithmetic sum
            crc16   CRC16 (generating polynomial 0x11021)
            crc32   CRC32 (generating polynomial 0x4C11DB7)
            crc=n   CRC with a generating polynomial of n
    
        flags can be a combination of:
            1       One's complement
            2       Two's complement
            m       Mirror bytes
    In all cases it is the least significant 1, 2 or 4 bytes of the result that will be output, in the natural byte order for the processor. The CRC checksum is calculated as if the following code was called for each bit in the input, most significant bit of each byte first, augmented with size (1, 2 or 4) bytes of zeros, starting with a crc of 0:

        unsigned long
        crc(int bit,
            unsigned long oldcrc)
        {
          unsigned long newcrc = (oldcrc << 1) ^ bit;
          if (oldcrc & 0x80000000)
            newcrc ^= POLY;
          return newcrc;
        }
    
    POLY is the generating polynomial. The checksum is the result of the final call to this routine. If the mirror flag is given, the checksum is calculated with each byte bit-reversed, that is least-significant bit first, and then the result is also bit-reversed. If the 1 or 2 flag is given, the checksum is the one's or two's complement, respectively, of the result.

    Note that the above routine is not a very time efficient way to calculate the checksum. See any text on crc calculation for faster ways. For checksums of size 2 or 1, the needed precision in the calculations will also be correspondingly lower. Also note that the checksum is calculated over the bytes in the input plus a number of zero bytes equal to the checksum size.

    The linker will place the checksum byte(s) at the label __checksum in the segment CHECKSUM. This segment must be placed using the segment placement options like any other segment.

    Example:

    Calculate a 4 byte checksum using the generating polynomial 0x4C11DB7 and output the one's complement of the calculated value.
  • 4.51M - Fill ranges

    The command line option -h can be used to specify the ranges to fill. Normally, all ranges given in segment placement commands (-Z -P) into which any actual content (code or constant data) is placed are filled. For example:

        -Z(CODE)INTVEC=0-FF
        -Z(CODE)RCODE,CODE,CDATA0=0-7FFF,F800-FFFF
        -Z(DATA)IDATA0,UDATA0=8000-8FFF
    
    If INTVEC contains anything the range 0-FF will be filled. If RCODE, CODE or CDATA0 contains anything the ranges 0-7FFF and F800-FFFF will be filled. IDATA0 and UDATA0 are normally only place holders for variables, which means that the range 8000-8FFF will not be filled.

    The command line option -h can be used to explicitly specify which ranges to fill. Its syntax is:

    That is, it can have an optional segment type (which can be used to specify address space for architectures with multiple address spaces) and one or more address ranges. For example: or, equivalently, as segment type CODE is the default, This will cause the range 0-FFFF to be filled, regardless of what ranges are specified in segment placement commands. Under many circumstances the use of -h will not be needed.

    -h can be specified more than once, in order to specify fill ranges for more than one address space.

    -h does not currently restrict the ranges used for checksum calculation. This may change in a future revision.

  • Code Duplication (-K)

    Pack Segments (-P)

    Revised Segment Placement

    Expanded Segment Placement Range Syntax

    Function/Variable Level Linking

    ELF details

    Address Expressions

    UBROF versions

    Address Translation

    COFF Details

    Scatter Loading (-Q)

    Diagnostics Control (-w)

    Multiple output files (-O)

    Relocation areas (-V)

    Range errors

    Address space sharing (-U)

    MISRA C

    New Errors

    New Warnings

    Log of Minor Changes


    Copyright 2005 IAR Systems. All rights reserved.