From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XN1XH+nPH2F/QQAAWB0awg (envelope-from ) for ; Fri, 20 Aug 2021 11:53:13 -0400 Received: by simark.ca (Postfix, from userid 112) id 7115E1EDFB; Fri, 20 Aug 2021 11:53:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E256A1E4A3 for ; Fri, 20 Aug 2021 11:53:11 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2373539BE4BC for ; Fri, 20 Aug 2021 15:53:11 +0000 (GMT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id E4AC5385DC15 for ; Fri, 20 Aug 2021 15:52:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4AC5385DC15 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x434.google.com with SMTP id q11so14927906wrr.9 for ; Fri, 20 Aug 2021 08:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Uc4wZxokD4oB2hk5U4haFAH2ImIl+eBSw9hCATZPTc8=; b=TFz+KxM7xV7sEDQrmbI+v6f4BtoKFnTUZKfutitrD0CF5a/qQnnXZZeeUp9fhEa8oB orTCwJjDRA/1h/xQMS9vopthVMlqtDkzSN2GMT/VzISvoOvFVwy5DxpFSI90xx2KcXKK lKyp1A9dJZKxqtFN410N+/jmG1dLCgFyJUuqOOJqJFrp0u+fFtHKcWySChOhlfQJ7xmh QOp9x8XuZYAOsjaft1OVvjwXOKo/a9i1f2ELG7/iD5fWg8bduSA33ouCgff2TkET3/4u v18XrsyDMAoaAQDsmjueokSbLd8EOUDQaAX7xPLNxNfQ3MR5EOlh0Gb+eu5PpM5HRTJs lxqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Uc4wZxokD4oB2hk5U4haFAH2ImIl+eBSw9hCATZPTc8=; b=Dd/d8eEiqjQGH5lZ8XdxeT7iYDolWCp25tQWp2ZhNzvKmobRRvNL7cNpSZE6gWUXlo 3WWNDKJm6fRbsEAg4KrKRQvJNwj+5y7E18E1tU16ZI39TkdgxodziYJrAFD/CHi38+p3 nNSLa9gmQWe5Yh7v9p+01E+iTwF54+d01a/pQySmdbikxEz6cmZ6SuxRly/7ufqWk+9r UAAtdyslQVvr1xEX0zcUUECgBy6b5casttxmqXWshhOIerIN64B8MNZfMq5gEauHaCsc RbrWqf6XfKHJNUrIgWXpR2iQeYVIbO4V9pPGSM9rGHHGD6MvXvtiYvjJ2jQPa1jF86XU 1/4w== X-Gm-Message-State: AOAM531lMziS6wUc/M4YvmQhZ7tbKbzmPxarvVw6IONonSqcNmpoj4pz 2fiE4sRWKrqqU/G0thrpBUJY3g== X-Google-Smtp-Source: ABdhPJxV9opCLXMXv+FcWQFS1Pxu9R2JrWQdZfsHFYfG89FARX4w3kBuLGSa2VQI/qnhDvKxfRHmeQ== X-Received: by 2002:adf:c681:: with SMTP id j1mr10779208wrg.119.1629474768996; Fri, 20 Aug 2021 08:52:48 -0700 (PDT) Received: from localhost (host86-188-49-44.range86-188.btcentralplus.com. [86.188.49.44]) by smtp.gmail.com with ESMTPSA id a3sm6219393wrx.38.2021.08.20.08.52.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Aug 2021 08:52:48 -0700 (PDT) Date: Fri, 20 Aug 2021 16:52:47 +0100 From: Andrew Burgess To: "abdul.b.ijaz" Subject: Re: [PATCH 1/1] gdb: Fix arrays of variable length strings for FORTRAN Message-ID: <20210820155247.GA2581@embecosm.com> References: <20210820110638.26648-1-abdul.b.ijaz@intel.com> <20210820110638.26648-2-abdul.b.ijaz@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20210820110638.26648-2-abdul.b.ijaz@intel.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 16:37:56 up 3 days, 4:34, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: abdul.b.ijaz@intel.com, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * abdul.b.ijaz via Gdb-patches [2021-08-20 13:= 06:38 +0200]: > GDB is not able to print arrays of FORTRAN variable length strings > when dwarf info contains DW_AT_string_length only regarding the string > length information. So handing of dynamic array is updated to handle > such cases. Thanks for working on this. I have some feedback, see below... >=20 > Suppose we have >=20 > subroutine vla_array (arr1, arr2) > character (len=3D*):: arr1 (:) > character (len=3D5):: arr2 (:) >=20 > print *, arr1 ! break-here > print *, arr2 > end subroutine vla_array >=20 > The "print arr1" and "print arr2" command at the "break-here" line > gives the following output: >=20 > (gdb) print arr1 > $1 =3D ( > (gdb) print arr2 > $2 =3D ('abcde', 'abcde', 'abcde') > (gdb) ptype arr1 > type =3D character*(*) (5) > (gdb) ptype arr2 > type =3D character*5 (3) >=20 > So GDB is able to print the array of string with static length but for > variable length it fail to do so. For this case now improve handling of > the TYPE_CODE_STRING code in dynamic array length resolving function to s= et > the static length of strings as well when only DW_AT_string_length is giv= en > in the dwarf info. >=20 > Dwarf info using Intel=AE Fortran Compiler for such case contains followi= ng: > <1>: Abbrev Number: 12 (DW_TAG_string_type) > DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 > <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_objec= t_address; DW_OP_plus_uconst: 8) I don't think the extra indentation before "DW_AT_string_length" is correct here, this attribute is a child of the DW_TAG_string_type, right? Not a child of the DW_AT_name. >=20 > After fixing it and compiling using Intel=AE Fortran Compiler now gdb sho= ws > following: >=20 > (gdb) p arr1 > $1 =3D ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefgh= ij') > (gdb) p arr2 > $2 =3D ('abcde', 'abcde', 'abcde') > (gdb) ptype arr1 > type =3D character*10 (5) > (gdb) ptype arr2 > type =3D character*5 (3) >=20 > gdb/ChangeLog: > 2021-08-20 Abdul Basit Ijaz >=20 > * gdbtypes.c (resolve_dynamic_array_or_string): Improve handling > of TYPE_CODE_STRING code to use return value of create_string_type > outcome for this case. > * c-valprint.c (c_value_print_inner): Handle String type code > in the same way as the Array type code. >=20 > gdb/testsuite/ChangeLog: > 2021-08-20 Abdul Basit Ijaz >=20 > * gdb.fortran/vla-array.f90: New fie. > * gdb.fortran/vla-array.exp: New fie. >=20 > 2021-08-20 Abdul Basit Ijaz > --- > gdb/c-valprint.c | 1 + > gdb/gdbtypes.c | 12 ++++-- > gdb/testsuite/gdb.fortran/vla-array.exp | 57 +++++++++++++++++++++++++ > gdb/testsuite/gdb.fortran/vla-array.f90 | 44 +++++++++++++++++++ > 4 files changed, 110 insertions(+), 4 deletions(-) > create mode 100644 gdb/testsuite/gdb.fortran/vla-array.exp > create mode 100644 gdb/testsuite/gdb.fortran/vla-array.f90 >=20 > diff --git a/gdb/c-valprint.c b/gdb/c-valprint.c > index 9c82869525f..e5a8e122676 100644 > --- a/gdb/c-valprint.c > +++ b/gdb/c-valprint.c > @@ -426,6 +426,7 @@ c_value_print_inner (struct value *val, struct ui_fil= e *stream, int recurse, > switch (type->code ()) > { > case TYPE_CODE_ARRAY: > + case TYPE_CODE_STRING: > c_value_print_array (val, stream, recurse, options); > break; I don't understand what part this change plays in this patch. I can see below how you're now creating values with TYPE_CODE_STRING instead of TYPE_CODE_ARRAY, but then I'd expect these to be covered by the existing handling of TYPE_CODE_STRING in f_language::value_print_inner. Of course, if you forced the language to C while inside the Fortran frame and tried to print the string value then I guess maybe you'd hit this case, but I don't think your test does this, and if that is the case you're covering here it might be worth splitting this into a separate commit to make the split crystal clear. > =20 > diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c > index 74ad5d6f7fe..1444c5feb6c 100644 > --- a/gdb/gdbtypes.c > +++ b/gdb/gdbtypes.c > @@ -2312,8 +2312,9 @@ resolve_dynamic_array_or_string (struct type *type, > range_type =3D resolve_dynamic_range (range_type, addr_stack, resolve_= p); > =20 > ary_dim =3D check_typedef (TYPE_TARGET_TYPE (type)); > - if (ary_dim !=3D NULL && ary_dim->code () =3D=3D TYPE_CODE_ARRAY) > - elt_type =3D resolve_dynamic_array_or_string (ary_dim, addr_stack, r= esolve_p); > + if (ary_dim !=3D NULL && (ary_dim->code () =3D=3D TYPE_CODE_ARRAY > + || ary_dim->code () =3D=3D TYPE_CODE_STRING)) > + elt_type =3D resolve_dynamic_array_or_string (ary_dim, addr_stack); > else > elt_type =3D TYPE_TARGET_TYPE (type); > =20 > @@ -2337,8 +2338,11 @@ resolve_dynamic_array_or_string (struct type *type, > else > bit_stride =3D TYPE_FIELD_BITSIZE (type, 0); > =20 > - return create_array_type_with_stride (type, elt_type, range_type, NULL, > - bit_stride); > + if (type->code () =3D=3D TYPE_CODE_STRING) > + return create_string_type (type, elt_type, range_type); I wonder if we should be doing anything with the bit_stride here? I'm not sure if it makes sense for the bit_stride to be anything other than zero, but at the very least it feels like we should throw an error if the stride is not zero .... > + else > + return create_array_type_with_stride (type, elt_type, range_type, NU= LL, > + bit_stride); > } > =20 > /* Resolve dynamic bounds of members of the union TYPE to static > diff --git a/gdb/testsuite/gdb.fortran/vla-array.exp b/gdb/testsuite/gdb.= fortran/vla-array.exp > new file mode 100644 > index 00000000000..a9223576bbd > --- /dev/null > +++ b/gdb/testsuite/gdb.fortran/vla-array.exp > @@ -0,0 +1,57 @@ > +# Copyright 2021 Free Software Foundation, Inc. > + > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see . > + > +standard_testfile ".f90" > +load_lib "fortran.exp" > + > +if {[skip_fortran_tests]} { return -1 } > + > +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \ > + {debug f90 quiet}] } { > + return -1 > +} > + > +if ![fortran_runto_main] { > + untested "could not run to main" > + return -1 > +} > + > +# Try to access vla string / vla string array / string array values Full stop at the end of the comment. Thanks, Andrew > +gdb_breakpoint [gdb_get_line_number "arr_vla1-print"] > +gdb_continue_to_breakpoint "arr_vla1-print" > + > +# GFortran does not emit DW_TAG_string_type for array of variable length > +# string. > +if [test_compiler_info "gcc*"] { setup_xfail *-*-* gcc/101826 } > +gdb_test "print arr_vla1" \ > + " =3D \\\('vlaaryvlaary', 'vlaaryvlaary', 'vlaaryvlaary', 'vlaaryvla= ary', 'vlaaryvlaary'\\\)" \ > + "print vla string array" > + > +if [test_compiler_info "gcc*"] { setup_xfail *-*-* gcc/101826 } > +gdb_test "ptype arr_vla1" \ > + "type =3D character\\*12 \\(5\\)" \ > + "print variable length string array type" > +gdb_test "print arr_vla2" \ > + " =3D 'vlaary'" \ > + "print variable length string" > +gdb_test "ptype arr_vla2" \ > + "type =3D character\\*6" \ > + "print variable length string type" > +gdb_test "print arr2" \ > + " =3D \\\('vlaaryvla', 'vlaaryvla', 'vlaaryvla'\\\)" \ > + "print string array" > +gdb_test "ptype arr2" \ > + "type =3D character\\*9 \\(3\\)" \ > + "print string array type" > diff --git a/gdb/testsuite/gdb.fortran/vla-array.f90 b/gdb/testsuite/gdb.= fortran/vla-array.f90 > new file mode 100644 > index 00000000000..612e84fe213 > --- /dev/null > +++ b/gdb/testsuite/gdb.fortran/vla-array.f90 > @@ -0,0 +1,44 @@ > +! Copyright 2021 Free Software Foundation, Inc. > +! > +! This program is free software; you can redistribute it and/or modify > +! it under the terms of the GNU General Public License as published by > +! the Free Software Foundation; either version 3 of the License, or > +! (at your option) any later version. > +! > +! This program is distributed in the hope that it will be useful, > +! but WITHOUT ANY WARRANTY; without even the implied warranty of > +! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +! GNU General Public License for more details. > +! > +! You should have received a copy of the GNU General Public License > +! along with this program. If not, see . > + > +subroutine vla_array_func (arr_vla1, arr_vla2, arr2) > + character (len=3D*):: arr_vla1 (:) > + character (len=3D*):: arr_vla2 > + character (len=3D9):: arr2 (:) > + > + print *, arr_vla1 ! arr_vla1-print > + print *, arr_vla2 > + print *, arr2 > +end subroutine vla_array_func > + > +program vla_array_main > +interface > + subroutine vla_array_func (arr_vla1, arr_vla2, arr2) > + character (len=3D*):: arr_vla1 (:) > + character (len=3D*):: arr_vla2 > + character (len=3D9):: arr2 (:) > + end subroutine vla_array_func > +end interface > + character (len=3D9) :: arr1 (3) > + character (len=3D6) :: arr2 > + character (len=3D12) :: arr3 (5) > + > + arr1 =3D 'vlaaryvla' > + arr2 =3D 'vlaary' > + arr3 =3D 'vlaaryvlaary' > + > + call vla_array_func (arr3, arr2, arr1) > + > +end program vla_array_main > --=20 > 2.31.1 >=20