This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TMS570LS0432: Using palign on a GROUP of sections

Expert 1226 points
Part Number: TMS570LS0432


Tool/software: TI C/C++ Compiler

Can the linker palign directive be used on a GROUP of sections?

The documentation describes the handling of alignment for a GROUP:

You can use binding, alignment, or named memory to allocate a GROUP in the same manner as a single
output section.

...

When you use the GROUP option, binding, alignment, or allocation into named memory can
be specified for the group only. You cannot use binding, named memory, or alignment for
sections within a group.

I don't see any place where it specifically describes alignment-with-padding for a GROUP.  I had assumed that the palign directive would be applicable, but in my testing with TI v17.3.0.STS and TI v5.2.8 I'm not seeing any padding for the GROUP I'm defining when using the following in the linker .cmd file:

SECTIONS
{
    mysolosection0 : > FLASH0, palign(8), crc_table(crcTable, algorithm=TMS570_CRC64_ISO)

    GROUP (group1) {
        mysection*
    } > FLASH0, palign(8), crc_table(crcTable, algorithm=TMS570_CRC64_ISO)
}

Specifically, I'm seeing the following in the .map file:

  output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
mysection*
*          0    00000020    00000005     
                  00000020    00000001     sections.obj (mysection1:retain)
                  00000021    00000001     sections.obj (mysection2:retain)
                  00000022    00000001     sections.obj (mysection3:retain)
                  00000023    00000001     sections.obj (mysection4:retain)
                  00000024    00000001     sections.obj (mysection5:retain)

mysolosection0
*          0    00000028    00000008     
                  00000028    00000001     sections.obj (mysolosection0:retain)
                  00000029    00000007     --HOLE-- [fill = 0]
...

LINKER GENERATED CRC TABLES

crcTable @ 000003c8 records: 2, size/record: 24, table size: 56
    mysection*: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000020, size=00000005, CRC=8d8d8da38e000003
    mysolosection0: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000028, size=00000008, CRC=8e00000000000003

What I'm hoping to see in first that each entry in the CRC table has a size that is a multiple of 64 bits, for ease when computing the CRC64 in our code, and second that there are well-defined HOLEs covering any needed padding.

--thx

  • Thank for notifying us of the problem, and submitting a concise test case.  I can reproduce the same result.  I filed CODEGEN-2181 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 1138,

    palign may be applied to a GROUP. If you remove palign(8) on mysolosection0, you will observe that its start address will remain 0x00000028 but its size will change to 1. You don't see any holes in the map file because palign is applied to the group, not to the sections within the group. If you want each mysection* aligned, you will need palign(8) on each of the sections, not on the group.

    Thanks,
    Dunni

  • Hello Dunni,

    Thank you for following up on my report! What you describe is exactly the behavior that I expected to see, and exactly the behavior we need for our CRC code to work correctly.

    In other words, I do not want each mysection* to be individually aligned or padded. I only want the total set of those sections combined together into a group to be aligned and padded.

    Unfortunately, as I described above, that is not what I saw. Ignoring for a moment that there was no --HOLE-- listed in the map file for GROUP group1, you can also see that the length of "mysection*" is listed as 5 in the output sections portion of the map file, and the size is listed as 5 in the CRC TABLES portion of the map file.

    --thx
  • CODEGEN-2181 lists this issue as "This is not a bug. palign on GROUP works as expected."

    I believe that my tests case above demonstrates that palign is not working on a GROUP. Can you provide a test case showing that palign does work on a GROUP?

    --thx
  • Hello 1138,

    An output section is what you probably want to use, not GROUP. Try collecting mysection* into an output section and then apply palign(8) on the output section. For example,

    SECTIONS
    {
        mysolosection0 : > FLASH0, palign(8), crc_table(crcTable, algorithm=TMS570_CRC64_ISO)

        mysection : { *(mysection*) } > FLASH0, palign(8), crc_table(crcTable, algorithm=TMS570_CRC64_ISO)
    }

    Thanks,
    Dunni

  • Excellent, thank you, it does look like that will do just what we need at the current time, rather than using a GROUP.

    We have discussed the possibility that we may have a need to more tightly-control the ordering of certain sections, which might lead us to revisit the status of GROUP support.

    From a process point of view, I would generally assume that you'd be interested in evaluating whether or not palign is working on a GROUP, in case there's a need to track it as a known issue or just to update the documentation.

    --thx
  • 1138,

    palign(8) on GROUP causes the size of the group to be a multiple of 8. However, it does not change the size of individual input sections contained in the group.

    In your example, if you remove palign(8) on mysolosection0 but leave palign(8) on the GROUP, you will observe that its start address for mysolosection0 will remain 0x00000028 but its size will change to 1.  

    Therefore, my conclusion at this time is that palign works as expected on GROUP.

    Thanks,
    Dunni

  • Hello Dunni,

    I'm afraid I just don't understand. Why are we talking about mysolosection0 at all? I don't see how it is relevant to whether or not palign works on a GROUP. mysolosection0 is not part of the GROUP group1.

    --thx
  • Hello 1138,

    I should have mentioned first that GROUP output sections are strictly logical entities that are not represented in map files. Using your initial linker command file and map file, mysection* is the name of the output section containing  mysection[1-5] input sections. Output section mysection* is contained within GROUP group1. In your example, palign(8) introduces padding to group1. However, GROUPs are not represented in the map file. You can apply palign to a GROUP as well as output sections. palign on an output section will change its size. palign on a group will add padding to the group. However, it will not change the size of the output sections contained in the group. If you want to add padding to an output section, then palign will need to be applied directly to the output section.

    I refer to mysolosection0 in your example only to show that padding is indeed being added to the GROUP and this padding affects the start address of mysolosection0. Alternatively, try setting a fill value for FLASH0 then the map file will show the hole the the padding on the group introduces.

    Regarding your initial concern about computing CRC64 in your code, did you encounter any issues? I didn't think that you would considering that the last 8-bytes if the "invisible group" are padded with zeros.

    I hope you find this explanation helpful. Please let me know if you need further information.

    Thanks,
    Dunni