fortran, debug: Fix up DW_AT_rank [PR103315]

Message ID 20211119094025.GL2646553@tucnak
State Committed
Headers
Series fortran, debug: Fix up DW_AT_rank [PR103315] |

Commit Message

Jakub Jelinek Nov. 19, 2021, 9:40 a.m. UTC
  Hi!

For DW_AT_rank we were emitting
        .uleb128 0x4    # DW_AT_rank
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x1c
        .byte   0x6     # DW_OP_deref
on 64-bit and
        .uleb128 0x4    # DW_AT_rank
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x10
        .byte   0x6     # DW_OP_deref
on 32-bit.  I think this is wrong, as dtype.rank field in the descriptor
has unsigned char type, not pointer type nor pointer sized integral.
E.g. if we have a
    REAL :: a(..)
dummy argument, which is passed as a reference to the function descriptor,
we want to evaluate a->dtype.rank.  The above DWARF expressions perform
*(uintptr_t *)(a + 0x1c)
and
*(uintptr_t *)(a + 0x10)
respectively.  The following patch changes those to:
        .uleb128 0x5    # DW_AT_rank
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x1c
        .byte   0x94    # DW_OP_deref_size
        .byte   0x1
and
        .uleb128 0x5    # DW_AT_rank
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x10
        .byte   0x94    # DW_OP_deref_size
        .byte   0x1
which perform
*(unsigned char *)(a + 0x1c)
and
*(unsigned char *)(a + 0x10)
respectively.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2021-11-19  Jakub Jelinek  <jakub@redhat.com>

	PR debug/103315
	* trans-types.c (gfc_get_array_descr_info): Use DW_OP_deref_size 1
	instead of DW_OP_deref for DW_AT_rank.


	Jakub
  

Comments

Mikael Morin Nov. 21, 2021, 11:52 a.m. UTC | #1
Le 19/11/2021 à 10:40, Jakub Jelinek via Fortran a écrit :
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
Hello,

you know probably better than me or any fortran maintainer whether it’s 
good or bad.
So OK from the fortran side.
  

Patch

--- gcc/fortran/trans-types.c.jj	2021-11-12 15:54:21.000000000 +0100
+++ gcc/fortran/trans-types.c	2021-11-18 15:13:45.131281198 +0100
@@ -3459,8 +3459,8 @@  gfc_get_array_descr_info (const_tree typ
       if (!integer_zerop (dtype_off))
 	t = fold_build_pointer_plus (t, rank_off);
 
-      t = build1 (NOP_EXPR, build_pointer_type (gfc_array_index_type), t);
-      t = build1 (INDIRECT_REF, gfc_array_index_type, t);
+      t = build1 (NOP_EXPR, build_pointer_type (TREE_TYPE (field)), t);
+      t = build1 (INDIRECT_REF, TREE_TYPE (field), t);
       info->rank = t;
       t = build0 (PLACEHOLDER_EXPR, TREE_TYPE (dim_off));
       t = size_binop (MULT_EXPR, t, dim_size);