From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29232 invoked by alias); 4 Jul 2013 11:49:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 29218 invoked by uid 89); 4 Jul 2013 11:49:33 -0000 X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Jul 2013 11:49:26 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 04 Jul 2013 04:49:24 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by AZSMGA002.ch.intel.com with ESMTP; 04 Jul 2013 04:49:23 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.52]) by IRSMSX103.ger.corp.intel.com ([169.254.3.35]) with mapi id 14.03.0123.003; Thu, 4 Jul 2013 12:49:22 +0100 From: "Agovic, Sanimir" To: Chris January CC: "gdb@sourceware.org" , "Boell, Keven" , "Weinmann, Christoph T" Subject: RE: Variable Length Arrays (VLA) proposal Date: Thu, 04 Jul 2013 11:49:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A71762A9D7@IRSMSX105.ger.corp.intel.com> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> <1372434039.2950.12.camel@gumtree> <0377C58828D86C4588AEEC42FC3B85A71762A7F2@IRSMSX105.ger.corp.intel.com> <1372929205.2796.18.camel@gumtree> In-Reply-To: <1372929205.2796.18.camel@gumtree> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-SW-Source: 2013-07/txt/msg00020.txt.bz2 PiA+IEJyZWFrcG9pbnQgMSwgdGVzdCAoKSBhdCB2bGEuZjkwOjQNCj4gPiA0 ICAgICAgICAgICBBTExPQ0FURSh2bGEgKDMsIDQsIDUpKQ0KPiA+ICQxID0g PG5vdCBhbGxvY2F0ZWQ+DQo+ID4gdHlwZSA9IGludGVnZXIoa2luZD00KSwg QUxMT0NBVEFCTEUgKDA6MSwwOjEsMDoxKQ0KPiANCj4gVGhpcyBoaWdobGln aHRzIGFub3RoZXIgaXNzdWVzIGltcGxlbWVudGluZyBWTEEuIFdoZW4gcHJp bnRpbmcgYSB0eXBlDQo+IChlLmcuIGluIGYtdHlwZXByaW50LmMpIHlvdSBk b24ndCBoYXZlIHRoZSB2YWx1ZSBvZiB0aGUgdmFyaWFibGUgYW5kDQo+IHRo ZXJlZm9yZSB5b3UgY2FuJ3QgZXZhbHVhdGUgdGhlIERXX0FUX2xvd2VyX2Jv dW5kLCBEV19BVF91cHBlcl9ib3VuZCwNCj4gRFdfQVRfYWxsb2NhdGVkLCBl dGMuIHNpbmNlIHRoZXkgdXN1YWxseSB1c2VzIERXX09QX3B1c2hfb2JqZWN0 X2FkZHJlc3MNCj4gYW5kIHdlIGRvbid0IGhhdmUgdGhlIHZhbHVlIGFkZHJl c3MgaW4gZl90eXBlX3ByaW50IGFuZCBmcmllbmRzLiBTbyB0bw0KPiBwcmlu dCByZWxpYWJseSBwcmludCB0eXBlIHR5cGUgb2YgYW4gZXhwcmVzc2lvbiBH REIgYWN0dWFsbHkgbmVlZHMgdG8NCj4gZXZhbHVhdGUgaXQsIHNvbWV0aGlu ZyBpdCBoYXNuJ3QgbmVlZGVkIHRvIGRvIGJlZm9yZS4NCg0KQWZhaWsgZ2Ri IGRvZXMgYSBjb21iaW5hdGlvbiBvZjoNCg0KY29uc3QgY2hhciAqIGV4cCA9 IFsuLi5dDQpzdHJ1Y3QgZXhwcmVzc2lvbiAqZXhwciA9IHBhcnNlX2V4cHJl c3Npb24gKGV4cCk7DQpzdHJ1Y3QgdmFsdWUgKnZhbCA9IGV2YWx1YXRlX3R5 cGUgKGV4cHIpOw0KWy4uLl0NCg0KZm9yIHdoYXRpcy9wdHlwZSB0aGVyZWZv cmUgd2Ugc2hvdWxkIGJlIGZpbmUgYXMgd2UgaGF2ZSBhIHZhbHVlIGluIHBs YWNlLg0KDQogLVNhbmltaXINCkludGVsIEdtYkgKRG9ybmFjaGVyIFN0cmFz c2UgMQo4NTYyMiBGZWxka2lyY2hlbi9NdWVuY2hlbiwgRGV1dHNjaGxhbmQK U2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBGZWxka2lyY2hlbiBiZWkgTXVlbmNo ZW4KR2VzY2hhZWZ0c2Z1ZWhyZXI6IENocmlzdGlhbiBMYW1wcmVjaHRlciwg SGFubmVzIFNjaHdhZGVyZXIsIERvdWdsYXMgTHVzawpSZWdpc3Rlcmdlcmlj aHQ6IE11ZW5jaGVuIEhSQiA0NzQ1NgpVc3QuLUlkTnIuL1ZBVCBSZWdpc3Ry YXRpb24gTm8uOiBERTEyOTM4NTg5NQpDaXRpYmFuayBGcmFua2Z1cnQgYS5N LiAoQkxaIDUwMiAxMDkgMDApIDYwMDExOTA1Mgo= >From gdb-return-42321-listarch-gdb=sources.redhat.com@sourceware.org Thu Jul 04 12:17:36 2013 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 24176 invoked by alias); 4 Jul 2013 12:17:36 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 24163 invoked by uid 89); 4 Jul 2013 12:17:35 -0000 X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Jul 2013 12:17:34 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 04 Jul 2013 05:18:58 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga002.fm.intel.com with ESMTP; 04 Jul 2013 05:17:31 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Jul 2013 13:16:46 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.52]) by IRSMSX152.ger.corp.intel.com ([169.254.6.125]) with mapi id 14.03.0123.003; Thu, 4 Jul 2013 13:16:46 +0100 From: "Agovic, Sanimir" To: Jan Kratochvil CC: "gdb@sourceware.org" , "Boell, Keven" , "Weinmann, Christoph T" , "Chris January (chris.january@allinea.com)" , "Joel Brobecker (brobecker@adacore.com)" Subject: RE: Variable Length Arrays (VLA) proposal Date: Thu, 04 Jul 2013 12:17:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A71762AA40@IRSMSX105.ger.corp.intel.com> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> <20130702133712.GA17311@host2.jankratochvil.net> In-Reply-To: <20130702133712.GA17311@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-07/txt/msg00021.txt.bz2 Content-length: 2846 Hello Jan, thanks for your feedback. > On Fri, 28 Jun 2013 15:01:25 +0200, Agovic, Sanimir wrote: > > We've created three proposals, how VLA support can be added to FSF GDB. >=20 > FYI this plan is dealing various ways only with item (1) of my "plan" > plan: VLA (Variable Length Arrays) and Fortran dynamic types > http://sourceware.org/ml/gdb/2012-11/msg00094.html > Tackling item (1) first is rather a ration decision to get started and to g= ain some practical experience on the gdb type system. We will have a closer loo= k=20 on the remaining items on the go, especially on the check_typedef problem. > > (2) > > Type normalization: > > > > This proposal is similar to Jan's approach [1] in transforming dynamic = values > > of attributes into static ones: > > > > 1) resolve all dynamic attributes > > 2) create a copy of the type and assign the resolved attributes from s= tep 1) > > > This your proposal (2) avoids fixing the fragile check_typedef usage but > I understand that is a different bug from the Fortran VLA-types bug. Proposal (3) deals with some side effects present in check_typedef, we may combine the proposals and fix the remaining issues until check_typedef=20 gets obsolete. > One needs to be careful about item (1) of my "plan": val_print / c_val_pr= int > / LA_VAL_PRINT passing address and type passed separately. But it may wo= rk. > Current archer-jankratochvil-vla has some hack for it in pascal_val_print; > FYI pascal (fpc) needs similar dynamic types for its strings. >=20 Thanks for pointing out Pascal. Now we have Fortran, C, ADA, and Pascal on = our radar. > > (3) > > Split struct type: > > > > The idea behind this proposal is to reflect the difference of types (dy= namic/ > > static attributes) in the type system used in GDB. At the moment we con= sider the > > following types: > > > > - struct type > > - struct static_type > > - struct dynamic type > > - struct typedef_type >=20 > This seems to me as an implementation variant of the proposal (1). The > current inferior type system is horrible but I did not consider its > refactorization meaningful before GDB starts to use C++; which currently = does > not seem to happen soon. > Imho we should consider (3) as a viable option independent of C++ usage. I`m afraid that the discussion about pro/con C++ is going to harm GDB=20 development. However, we may discuss the benefit of a transition to C++ in the _context_ of the gdb type system during cauldron2013 (BoF) and on the ML. -Sanimir Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052