Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC

Bug #1861283 reported by Robert Dumitru
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
New
Low
Przemyslaw Wirkus

Bug Description

We have the following code that runs on a cortex a9 of a Renesas RZ A1 board and involves the declaration of a variable length array. I will present here the code, the debug info for the variable and the disassembly code.

The sample code:

int main(void)
{
 volatile int n;
 int a = 1000;

 int id_size = sizeof(cTaskList) / sizeof(V4_T_CTSK);
        ID id[id_size];

        for(;;){
       for(n=0; n<id_size; n++){
      (cTaskList[n].task)();
      id[n] = nn;
       }
        }
}

Compiling and building it using the ARM GCC toolchain 7.2.1 we obtain the following debug information for the variable length array id and also the following assembly code:

Debug dump for id:
 <2><9e2>: Abbrev Number: 38 (DW_TAG_variable)
    <9e3> DW_AT_name : id
    <9e6> DW_AT_decl_file : 1
    <9e7> DW_AT_decl_line : 85
    <9e8> DW_AT_type : <0x9f1>
    <9ec> DW_AT_location : 3 byte block: 91 68 6 (DW_OP_fbreg: -24; DW_OP_deref)

The disassembly code:

          main():
20021230: push {r11, lr}
20021234: add r11, sp, #4
20021238: sub sp, sp, #24
82 int a = 1000;
2002123c: mov r3, #1000 ; 0x3e8
20021240: str r3, [r11, #-8]
84 int id_size = sizeof(cTaskList) / sizeof(V4_T_CTSK);
20021244: mov r3, #13
20021248: str r3, [r11, #-12]
85 ID id[id_size];/* <-- debug session terminates with this declaration */
2002124c: ldr r3, [r11, #-12]
20021250: sub r12, r3, #1
20021254: str r12, [r11, #-16]
20021258: mov r3, r12
2002125c: add r3, r3, #1
20021260: mov r0, r3
20021264: mov r1, #0
20021268: mov r2, #0
2002126c: mov r3, #0
20021270: lsl r3, r1, #5
20021274: orr r3, r3, r0, lsr #27
20021278: lsl r2, r0, #5
2002127c: mov r3, r12
20021280: add r3, r3, #1
20021284: mov r0, r3
20021288: mov r1, #0
2002128c: mov r2, #0
20021290: mov r3, #0
20021294: lsl r3, r1, #5
20021298: orr r3, r3, r0, lsr #27
2002129c: lsl r2, r0, #5
200212a0: mov r3, r12
200212a4: add r3, r3, #1
200212a8: lsl r3, r3, #2
200212ac: add r3, r3, #3
200212b0: add r3, r3, #7
200212b4: lsr r3, r3, #3
200212b8: lsl r3, r3, #3
200212bc: sub sp, sp, r3
200212c0: mov r3, sp
200212c4: add r3, r3, #3
200212c8: lsr r3, r3, #2
200212cc: lsl r3, r3, #2
200212d0: str r3, [r11, #-20]
89 for(n=0; n<id_size; n++){

-data-evaluate-expression --thread 1 --frame 0 id

If we try to evaluate id before 200212d0: str r3, [r11, #-20] is executed we either get the wrong result or gdb will get the wrong size for id and crash with "../../gdb-7.8.2/gdb/utils.c:1062: internal-error: virtual memory exhausted.
After this code is executed -200212d0: str r3, [r11, #-20] the memory contains the correct values.

So maybe the code that writes the correct values to memory should be at the beginning of the function?

This causes a serious problem if we debug using an IDE based on Eclipse that has the Variables View open, because gdb will crash immediately after entering the main function and the user will have no clue why.

Please let me know if you need more details or my explanation is not clear enough.
I checked with gcc 9.2.1 20191025 and this still happens.

Best regards,
Robert

Revision history for this message
Joey Ye (jinyun-ye) wrote :

Will need sometime to reproduce with board or qemu. Should get back later to this.

Changed in gcc-arm-embedded:
importance: Undecided → Low
assignee: nobody → Przemyslaw Wirkus (wirkus)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.