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.

TMS470: bss byte alignment via palign

Hey folks,

I am hoping somebody may be able to help me out with a couple of questions in regards to byte alignment for bss and data via palign.

1. I have the following in my linker command file:

.data : palign(4), fill = 0xffffffff {} > DDR_MEM

.bss : palign(4), fill = 0xffffffff {} > DDR_MEM

Whilst this does work in giving me 4 byte alignment for the sections, for some reason there is a large hole at the end of bss, but not at the end of data:

bss:                    80b6cc20    000033e0     --HOLE--

data:                   80be1655    00000003     --HOLE--

Does anybody have an idea on why this is occurring?

 

2. I am trying to group bss, data, and a couple of other sections at the top of RAM by defining them in a group.

Is it possible to make use of the palign within a group block? I tried using the same syntax as above within the group block but received an error:

warning #10087-D: LOAD placement ignored for ".data": object is placed as part of "GROUP_2"

warning #10087-D: LOAD placement ignored for ".bss": object is placed as part of "GROUP_2"

  • Trevor Yates said:
    bss:                    80b6cc20    000033e0     --HOLE--

    For a palign(4), the maximum padding at the end of the section should be 3 bytes.  This might be a linker bug.  Please attach the map file to your next post.  If this is a bug, we will need a test case which allows us to reproduce the behavior.

    Trevor Yates said:
    Is it possible to make use of the palign within a group block?

    No.  The individual output sections listed in a group are not given any memory allocation specification, including palign.  Please see this wiki article.

    Thanks and regards,

    -George

  • Thanks for the swift reply George. We have since decided to align the group instead of the bss and data individually. Interestingly there is now a hole between the end of bss and the end of the group which matches the size of the original hole. My team lead is going to forward the information on to our TI support reps to see if it is indeed a bug as you suggested.

    Cheers

    Trevor