From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29964 invoked by alias); 19 Aug 2016 09:58:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29949 invoked by uid 89); 19 Aug 2016 09:58:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=examine, Hx-spam-relays-external:192.55.52.115, HX-HELO:mga14.intel.com, H*RU:mga14.intel.com X-HELO: mga14.intel.com Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Aug 2016 09:58:13 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 19 Aug 2016 02:58:12 -0700 X-ExtLoop1: 1 Received: from heckel-mobl3.ger.corp.intel.com (HELO [172.28.205.46]) ([172.28.205.46]) by fmsmga001.fm.intel.com with ESMTP; 19 Aug 2016 02:58:10 -0700 Subject: Re: [V4 00/21] Fortran dynamic array support To: Jan Kratochvil 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> <20160816135920.GA26624@host1.jankratochvil.net> Cc: "Weinmann, Christoph T" , gdb-patches@sourceware.org From: Bernhard Heckel Message-ID: <57B6D831.4080605@intel.com> Date: Fri, 19 Aug 2016 09:58:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160816135920.GA26624@host1.jankratochvil.net> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00194.txt.bz2 On 16/08/2016 15:59, Jan Kratochvil wrote: > 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 o= n 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 conte= nt. >> >> 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) =3D 6 > vs. > $23 =3D (( ( 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-com= puted > address. > > What is wrong is accessing 'varw' elements not in the first row of the ar= ray > 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_O= P_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_p= ush_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_m= ul) > and that just fetches the values from gfortran array descriptor - otherwi= se 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 =3D TYPE_LENGTH (elt_type); > - unsigned int elt_offs =3D elt_size * longest_to_int (index - lowerboun= d); > + unsigned int elt_offs =3D longest_to_int (index - lowerbound); > + LONGEST elt_stride =3D TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type)); > struct value *v; > > + if (elt_stride > 0) > + elt_offs *=3D elt_stride; > + else if (elt_stride < 0) > + { > + int offs =3D (elt_offs + 1) * elt_stride; > + > + elt_offs =3D TYPE_LENGTH (array_type) + offs; > + } > + else > + elt_offs *=3D 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_STR= IDE > for that. > > > Thanks, > Jan Hi Jan, here is the missing patch in your environment. https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html This patch handles strides in DWARF and your fortran program. Christoph's patch series was about strides in user input, for example=20 "print my_vla(1:10:2)" I will create a branch about all stride patches in the next weeks. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928