| Issue |
97476
|
| Summary |
[flang][debuginfo] Inconsistent debugger behavior when processing executables emitted by flang-new
|
| Labels |
flang
|
| Assignees |
|
| Reporter |
pawosm-arm
|
Consider simple program:
```
PROGRAM allocatable
IMPLICIT NONE
INTEGER, ALLOCATABLE, TARGET :: alloc2d(:, :)
ALLOCATE(alloc2d(-1:1, -2:2))
IF (ALLOCATED(alloc2d)) THEN
alloc2d(:, :) = -1
DEALLOCATE(alloc2d)
END IF
END PROGRAM
```
I've tried to compile it with gfortran and the old classic flang (each time with the `-O0 -g` flags), and I've observed (more or less) the same effect in gdb (after setting breakpoint at the ALLOCATE statement):
```
(gdb) b allocatable.f90:5
Breakpoint 1 at 0x40092c: file allocatable.f90, line 5.
(gdb) r
Starting program: /home/pawosm01/test_linear/allocatable
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, allocatable () at allocatable.f90:5
5 ALLOCATE(alloc2d(-1:1, -2:2))
(gdb) info locals
alloc2d = <not allocated>
(gdb)
```
When compiled with flang-new, I can observe a different behavior:
```
(gdb) b allocatable.f90:5
Breakpoint 1 at 0x2110: file allocatable.f90, line 5.
(gdb) r
Starting program: /home/pawosm01/test_linear/allocatable
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, _QQmain () at allocatable.f90:5
5 ALLOCATE(alloc2d(-1:1, -2:2))
(gdb) info locals
alloc2d = ()
(gdb)
```
Apparently, gdb can't figure out that the array was not allocated yet.
This has some nasty implications as I extended the program a bit:
```
PROGRAM minimal
IMPLICIT NONE
INTEGER :: int_arr1d(-1:1)
INTEGER :: int_arr2d(-1:1, -2:2)
LOGICAL :: logical_arr2d(-1:1, -2:2)
REAL :: real_arr1d(-1:1)
REAL :: real_arr2d(-1:1, -2:2)
INTEGER, ALLOCATABLE, TARGET :: alloc2d(:, :)
ALLOCATE(alloc2d(-1:1, -2:2))
IF (ALLOCATED(alloc2d)) THEN
alloc2d(:, :) = -1
DEALLOCATE(alloc2d)
END IF
END PROGRAM
```
When compiled with gfortran (and more or less the same when compiled with the old classic flang):
```
(gdb) b minimal.f90:10
Breakpoint 1 at 0x40092c: file minimal.f90, line 10.
(gdb) r
Starting program: /home/pawosm01/test_linear/minimal
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, minimal () at minimal.f90:10
10 ALLOCATE(alloc2d(-1:1, -2:2))
(gdb) info locals
alloc2d = <not allocated>
(gdb)
```
Notice, that uninitialized variables are not present.
When compiled with flang-new:
```
(gdb) b minimal.f90:10
Breakpoint 1 at 0x2110: file minimal.f90, line 10.
(gdb) r
Starting program: /home/pawosm01/test_linear/minimal
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, _QQmain () at minimal.f90:10
10 ALLOCATE(alloc2d(-1:1, -2:2))
(gdb) info locals
int_arr1d = (-134225856, 65535, -1431689840)
real_arr1d = (6.12227299e-41, -9.7203448e+33, 9.18340949e-41)
alloc2d = <error reading variable alloc2d (Cannot access memory at address 0x1000000000000)>
(gdb)
```
Now, some (but only some) of the uninitialized variables are shown, all of them with random values, and `alloc2d` has gone completely to the moon. Note that when doing experiments (adding more variables, some of them with user defined types) I've managed to make the information about `alloc2d` completely lost, which is the most unfortunate.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
