• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 588 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/AM6548: Pointer assignment problem on Cortex A53 with GCC

Thomas Mauer
Expert 4680 points
Part Number: AM6548

Tool/software: TI C/C++ Compiler

Dear Support Team,

We are facing an issue on the ARM Cortex A53 with pointers.

The issue is the following: When assigning the pointer value, the executed code returns a 64-bit swapped pointer.

        u8_g_tmp_ptr= (u8_t *)g_FgNrtIdnValues.MACAddr.pData;

For example, when the pointer is 0x0000000012345678, the  u8_g_tmp_ptr will become 0x1234567800000000.

We capture the error in below screenshot.

pData is a void pointer.

typedef struct tagELEMENTDATA

{

  WORD_A   wLen;                    ///< actual length of element

  WORD_A   wMaxLen;                 ///< maximum length of element

  void     *pData;                  ///< pointer to element data

}ELEMENTDATA;                       ///< Type definition of structure #tagELEMENTDATA

Can you please check if this is an error, or if we need to use it in a different way.

Regards,

 Thomas

  • 0
    TI__Guru**** 241595 points

    I'd like to have a look at the assembly code generated by the compiler.  From the command line run ...

    % arm-none-eabi-objdump -drwS final_executable.out > disassembly.txt

    Then attach the resulting text file to your next post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Expert 4680 points

    Hi George,

    Here is the extracted section.

    if (xstrncmp((char *)&ptr[0x2c], (char *)UCC_TEST_MSG_ID, xstrlen(UCC_TEST_MSG_ID)) == 0)
    8007a288: f9401ba0 ldr x0, [x29, #48]
    8007a28c: 9100b013 add x19, x0, #0x2c
    8007a290: 58000b00 ldr x0, 8007a3f0 <AMx_ethernetif_input+0x200>
    8007a294: 97fe91b0 bl 8001e954 <xstrlen>
    8007a298: 12003c00 and w0, w0, #0xffff
    8007a29c: 2a0003e1 mov w1, w0
    8007a2a0: 58000a80 ldr x0, 8007a3f0 <AMx_ethernetif_input+0x200>
    8007a2a4: 2a0103e2 mov w2, w1
    8007a2a8: aa0003e1 mov x1, x0
    8007a2ac: aa1303e0 mov x0, x19
    8007a2b0: 97fe920a bl 8001ead8 <xstrncmp>
    8007a2b4: 7100001f cmp w0, #0x0
    8007a2b8: 54000641 b.ne 8007a380 <AMx_ethernetif_input+0x190> // b.any
    {
    u8_g_tmp_ptr= /*(u8_t *)&g_FgNrtIdnValues.bArrMACAddr[0]; */
    (u8_t *)g_FgNrtIdnValues.MACAddr.pData;
    8007a2bc: 580009e0 ldr x0, 8007a3f8 <AMx_ethernetif_input+0x208>
    8007a2c0: b9400401 ldr w1, [x0, #4]
    8007a2c4: b9400800 ldr w0, [x0, #8]
    8007a2c8: d3607c00 lsl x0, x0, #32
    8007a2cc: aa010000 orr x0, x0, x1
    8007a2d0: aa0003e1 mov x1, x0
    u8_g_tmp_ptr= /*(u8_t *)&g_FgNrtIdnValues.bArrMACAddr[0]; */
    8007a2d4: 58000960 ldr x0, 8007a400 <AMx_ethernetif_input+0x210>
    8007a2d8: f9000001 str x1, [x0]
    for(int i= 2; i < 8; i++) // MAC: dest. <=> source & send to master
    8007a2dc: 52800040 mov w0, #0x2 // #2
    8007a2e0: b9004fa0 str w0, [x29, #76]
    8007a2e4: 14000018 b 8007a344 <AMx_ethernetif_input+0x154>
    {
    ptr[i]= ptr[i+6];
    8007a2e8: b9804fa0 ldrsw x0, [x29, #76]
    8007a2ec: 91001800 add x0, x0, #0x6
    8007a2f0: f9401ba1 ldr x1, [x29, #48]
    8007a2f4: 8b000021 add x1, x1, x0
    8007a2f8: b9804fa0 ldrsw x0, [x29, #76]
    8007a2fc: f9401ba2 ldr x2, [x29, #48]
    8007a300: 8b000040 add x0, x2, x0
    8007a304: 39400021 ldrb w1, [x1]
    8007a308: 39000001 strb w1, [x0]
    ptr[i+6]= *u8_g_tmp_ptr++;

    Regards, 

     Thomas

  • 0 in reply to Thomas Mauer
    TI__Guru**** 241595 points

    The assembly code looks correct.  However, my expertise in ARM assembly is less than I would like.  So, I still want to file a bug with the proper team.  Unfortunately, changes have occurred recently with the support of the GCC ARM compilers.  I am making some inquiries about where to file this bug.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 241595 points

    I presume you use the GCC ARM compiler that comes with the Processor SDK.  It has a location similar to ...

    C:\ti\gcc-linaro-7.2.1-2017.11-i686-mingw32_aarch64-elf

    Please collect a test case, then I am happy to submit it to Linaro for analysis.

    For the source file which contains the problem pointer assignment, please build it as before, but add these options: -E -o name_of_file.txt .  That preprocesses the file and writes it to the file named with the -o option.  Attach that file to your next post.

    Run the compiler with just the option --version and show the output.

    Show exactly how the compiler gets invoked on the problem source file. Please copy-n-paste the text, and do not use a screen shot.

    If you are not comfortable with posting these details, you are welcome to send it to me privately.

    Thanks and regards,

    -George