https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68889
Bug ID: 68889
Summary: Fortran/DWARF: Possible bug in the handling of
DW_AT_associated
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
See description at https://sourceware.org/ml/gdb-patches/2015-12/msg00245.html
Possibly related: PR 59438
Quote from that email (Andrew Burgess, [PATCH 0/2] Problems with
gdb.mi/mi-vla-fortran.exp):
In the test we have gdb stop at vla.f90:35, which looks like this:
pvla2 => vla2 ! pvla2-not-associated
Before this point, the pvla2 pointer variable is not associated, and
so, something like:
l = associated(pvla2)
Would return false. In order to determine if pvla2 is associated gdb
makes use of the DWARF DW_AT_associated property which is an attribute
of the DWARF type corresponding to pvla2.
The DW_AT_associated property for the type of pvla2 is this (newlines
added by me for clarity):
DW_AT_associated : 4 byte block: 97 6 30 2e \
(DW_OP_push_object_address; \
DW_OP_deref; DW_OP_lit0; \
DW_OP_ne)
So, take the address of the object (in this case the address is on the
stack), and use that to load an address sized block from memory, and
if that loaded block is not zero, then the the variable (pvla2) is
associated.
The problem is that gfortran does not initialise the block of memory
that the object address points to until the first time that pvla2 is
accessed. Before that time the contents of the memory are undefined,
and if gdb accesses them we will see undefined behaviour.
I've confirmed that above behaviour by using the '-fdump-tree-all'
option to gfortran, then examining the pseudo-C code that is dumped.
>From a compiler / code correctness point of view this behaviour is
perfectly understandable, and for performance, this is probably a win,
the problem (as I see it) is that a promise has been made in the
DWARF, which is not being honoured in the code. I think gfortran
either needs more complex DWARF, or to initialise the memory block for
associatable variables earlier on.
Given the above mistake, what follows is just undefined behaviour
kicking in; gdb reads the uninitialised memory, which happens to be
non-zero, so it believes pvla2 is associated, it then tries to figure
out what it's associated with, and reads yet more uninitialised memory.
