From patchwork Tue Aug 16 13:59:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kratochvil X-Patchwork-Id: 14612 Received: (qmail 58756 invoked by alias); 16 Aug 2016 13:59:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 58180 invoked by uid 89); 16 Aug 2016 13:59:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=longest, metzger X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Aug 2016 13:59:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 410C9C04B320; Tue, 16 Aug 2016 13:59:25 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7GDxLDl025340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Aug 2016 09:59:23 -0400 Date: Tue, 16 Aug 2016 15:59:20 +0200 From: Jan Kratochvil To: "Heckel, Bernhard" Cc: "Weinmann, Christoph T" , gdb-patches@sourceware.org Subject: Re: [V4 00/21] Fortran dynamic array support Message-ID: <20160816135920.GA26624@host1.jankratochvil.net> References: <88072818E0A3D742B2B1AF16BBEC65A7263D8247@IRSMSX107.ger.corp.intel.com> <20160707095439.GA6792@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263D990E@IRSMSX107.ger.corp.intel.com> <20160714182743.GA10672@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263E6F2E@IRSMSX107.ger.corp.intel.com> <20160715091352.GA8059@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263E8FD9@IRSMSX107.ger.corp.intel.com> <20160716151310.GA14331@host1.jankratochvil.net> <20160716151837.GA797@host1.jankratochvil.net> <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com> User-Agent: Mutt/1.6.2 (2016-07-01) X-IsSubscribed: yes Hi Bernhard, On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote: > I took a look at "p varw" issue. > > >From my point of view, the debug information for the location of varw is wrong. > > Set a breakpoint at line 68 and run. > "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase. > Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation > of "varw" is correct. From my point of view, the location expression of "varw" is wrong. > > If you manual examine the content at "loc(varw)" you see the right content. > > FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation. > > I attached the testcase + dwarf primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel VLA patch series - does PASS the testcase fine with gfortran DWARF so completely wrong the DWARF is not. Also you talk here only about starting address of 'varw'. But that is not a problem, the starting address in inferior + in GDB do match: varw(1, 1, 1) = 6 vs. $23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ) (gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled - the value 6 is really the first (1,1,1) value printed. The starting address is nothing special for GDB as starting address is adjusted/offseted by the inferior caller, GDB just reads the inferior-computed address. What is wrong is accessing 'varw' elements not in the first row of the array by GDB - because GDB needs to know the stride for it. Stride is described there in DWARF: <231> DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22 (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus) <23d> DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul) and that just fetches the values from gfortran array descriptor - otherwise the inferior Fortran function 'foo' would not work. Why do you think gfortran has the DWARF wrong? Do your GDB patches PASS with ifort? I no longer have ifort - I got a license from Markus Metzger many years ago, it was somehow complicated in Intel to get it for me and the license laster only one year. You would have to send me the ifort-built binary (or .s file). I have tried now to re-apply a part of the old working Intel VLA patch of value_subscripted_rvalue(): unsigned int elt_size = TYPE_LENGTH (elt_type); - unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound); + unsigned int elt_offs = longest_to_int (index - lowerbound); + LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type)); struct value *v; + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; + But it does not work (attached). Maybe because the stride of an array now appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type) while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE for that. Thanks, Jan --- ./gdb/valarith.c 2016-08-16 15:36:10.680313175 +0200 +++ ./gdb/valarith.c 2016-08-16 15:33:18.696930843 +0200 @@ -193,9 +193,22 @@ value_subscripted_rvalue (struct value * struct type *array_type = check_typedef (value_type (array)); struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type)); ULONGEST elt_size = type_length_units (elt_type); - ULONGEST elt_offs = elt_size * (index - lowerbound); + ULONGEST elt_offs = index - lowerbound; + LONGEST elt_stride = TYPE_FIELD_BITSIZE (array_type, 0); struct value *v; +if (elt_stride) fprintf(stderr,"value_subscripted_rvalue: elt_stride=%ld\n",elt_stride); + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; + if (index < lowerbound || (!TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED (array_type) && elt_offs >= type_length_units (array_type))) { --- ./gdb/valops.c 2016-08-16 15:36:10.694313288 +0200 +++ ./gdb/valops.c 2016-08-16 15:04:54.963343948 +0200 @@ -3826,7 +3826,7 @@ value_slice_1 (struct value *array, int struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type)); unsigned int elt_size, elt_offs; /* ATTRIBUTE_UNUSED: VLA bug: https://sourceware.org/ml/gdb-patches/2016-08/msg00099.html */ - LONGEST elt_stride ATTRIBUTE_UNUSED, ary_high_bound, ary_low_bound; + LONGEST elt_stride, ary_high_bound, ary_low_bound; struct value *v; int slice_range_size, i = 0, row_count = 1, elem_count = 1; @@ -3863,7 +3863,17 @@ value_slice_1 (struct value *array, int elt_offs = lowbound - ary_low_bound; elt_stride = TYPE_LENGTH (TYPE_INDEX_TYPE (array_type)); - elt_offs *= elt_size; +fprintf(stderr,"elt_stride=%d\n",elt_stride); + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; /* Check for valid user input. In case of Fortran this was already done in the calling function. */