This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error L6244E generated by ARMLINK after switching from ARMCC to ARMCLANG.

Hello,

Currently, I'm working on the transition of a project initially compiled with ARMCC (for an ARMv7 architecture) and now compiled with ARMCLANG (for an ARMv8 architecture).

With ARMLINK, I get the following error:

Error: L6244E: Load region LOAD_TTB address (0x0000f800) not aligned on a 16384 byte boundary.

Below is the scatter file sample:

LOAD_TTB 0xF800 0x4800
{
  CODE_TTB AlignExpr(+0, 0x4800)
  {
    ttb.o (+RO)
  }
}

I haven't found any information (especially in the links below) on why this error occurs now and if this error is a source of faults when running a program. Or I can safely use “--diag_suppress=6244”.

Do you have a rough explanation to help me to understand, Why switching to ARMCLANG generates this error with ARMLINK?

In addition, can you highlight a related documentation?

Thanks in advance.

---

Arm Compiler for Embedded Errors and Warnings Reference Guide: https://developer.arm.com/documentation/100074/latest/

Arm Compiler armlink User Guide: https://developer.arm.com/documentation/dui0803/l/?lang=en

https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54501/error-l6244e-region-not-aligned-on-cm33-secure-world-with-arm-v6-19-compiler

---

Parents
  • Hello,

    Thank you for your reply.

    In a file ttb.c, three tables are declared with the following attribute “__attribute__((at(0xFC00)))” (Originally compiled with ARMCC). Following the documentation “Migration and Compatibility Guide“, I changed the attribute to “__attribute__((section(".ARM.__at_0xFC00")))“.

    I then noticed that ARMLINK had added a PADDING zone in LOAD_TTB in place of one of the arrays with the attribute “__attribute__((section(".ARM.__at_0xFC00")))“. So I added "AlignExpr()" as suggested in the ARMLINK documentation « 8.12 Example of using expression evaluation in a scatter file to avoid padding »

    If AlignExpr() is undesirable in my case, I have two questions:

    1. Why does ARMLINK add a PAD section, knowing that this was not the case when the code was compiled with ARMCC?
    2. How can I avoid introducing a padding section?

    Extract from the memory map provided by ARMLINK:

      Load Region LOAD_TTB (Base: 0x0000f800, Size: 0x00004800, Max: 0x00004800, ABSOLUTE)
     
        Execution Region CODE_TTB (Base: 0x0000f800, Size: 0x00004800, Max: 0x00004800, ABSOLUTE)
     
        Base Addr    Size         Type   Attr      Idx    E Section Name        Object
     
        0x0000f800   0x00000400   Data   RO          134    .ARM.__at_0xF800    ttb.o
        0x0000fc00   0x00000400   PAD
        0x00010000   0x00004000   Data   RO          132    .ARM.__at_0x10000   ttb.o
     
     
     
      Load Region LR$$.ARM.__at_0xF800 (Base: 0x0000f800, Size: 0x00000000, Max: 0x00000400, ABSOLUTE)
     
        Execution Region ER$$.ARM.__at_0xF800 (Base: 0x0000f800, Size: 0x00000000, Max: 0x00000400, ABSOLUTE, UNINIT)
     
        **** No section assigned to this execution region ****
     
     
     
      Load Region LR$$.ARM.__at_0xFC00 (Base: 0x0000fc00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE)
     
        Execution Region ER$$.ARM.__at_0xFC00 (Base: 0x0000fc00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, UNINIT)
     
        Base Addr    Size         Type   Attr      Idx    E Section Name        Object
     
        0x0000fc00   0x00000400   Data   RO          133    .ARM.__at_0xFC00    ttb.o
    

    ---

    To answer your question:

    $ fromelf -z ttb.o

    ========================================================================
    ** Object/Image Component Sizes
    Code (inc. data) RO Data RW Data ZI Data Debug Object Name
    0                      0      18432            0           0      700               ttb.o
    Regards,
Reply
  • Hello,

    Thank you for your reply.

    In a file ttb.c, three tables are declared with the following attribute “__attribute__((at(0xFC00)))” (Originally compiled with ARMCC). Following the documentation “Migration and Compatibility Guide“, I changed the attribute to “__attribute__((section(".ARM.__at_0xFC00")))“.

    I then noticed that ARMLINK had added a PADDING zone in LOAD_TTB in place of one of the arrays with the attribute “__attribute__((section(".ARM.__at_0xFC00")))“. So I added "AlignExpr()" as suggested in the ARMLINK documentation « 8.12 Example of using expression evaluation in a scatter file to avoid padding »

    If AlignExpr() is undesirable in my case, I have two questions:

    1. Why does ARMLINK add a PAD section, knowing that this was not the case when the code was compiled with ARMCC?
    2. How can I avoid introducing a padding section?

    Extract from the memory map provided by ARMLINK:

      Load Region LOAD_TTB (Base: 0x0000f800, Size: 0x00004800, Max: 0x00004800, ABSOLUTE)
     
        Execution Region CODE_TTB (Base: 0x0000f800, Size: 0x00004800, Max: 0x00004800, ABSOLUTE)
     
        Base Addr    Size         Type   Attr      Idx    E Section Name        Object
     
        0x0000f800   0x00000400   Data   RO          134    .ARM.__at_0xF800    ttb.o
        0x0000fc00   0x00000400   PAD
        0x00010000   0x00004000   Data   RO          132    .ARM.__at_0x10000   ttb.o
     
     
     
      Load Region LR$$.ARM.__at_0xF800 (Base: 0x0000f800, Size: 0x00000000, Max: 0x00000400, ABSOLUTE)
     
        Execution Region ER$$.ARM.__at_0xF800 (Base: 0x0000f800, Size: 0x00000000, Max: 0x00000400, ABSOLUTE, UNINIT)
     
        **** No section assigned to this execution region ****
     
     
     
      Load Region LR$$.ARM.__at_0xFC00 (Base: 0x0000fc00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE)
     
        Execution Region ER$$.ARM.__at_0xFC00 (Base: 0x0000fc00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, UNINIT)
     
        Base Addr    Size         Type   Attr      Idx    E Section Name        Object
     
        0x0000fc00   0x00000400   Data   RO          133    .ARM.__at_0xFC00    ttb.o
    

    ---

    To answer your question:

    $ fromelf -z ttb.o

    ========================================================================
    ** Object/Image Component Sizes
    Code (inc. data) RO Data RW Data ZI Data Debug Object Name
    0                      0      18432            0           0      700               ttb.o
    Regards,
Children
No data