From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30263 invoked by alias); 28 Jun 2013 13:03:47 -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 30246 invoked by uid 89); 28 Jun 2013 13:03:46 -0000 X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_YP autolearn=ham version=3.3.1 Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 28 Jun 2013 13:03:45 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 28 Jun 2013 06:02:45 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by AZSMGA002.ch.intel.com with ESMTP; 28 Jun 2013 06:01:27 -0700 Received: from irsmsx106.ger.corp.intel.com (163.33.3.31) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Jun 2013 14:01:26 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.52]) by IRSMSX106.ger.corp.intel.com ([169.254.8.91]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 14:01:26 +0100 From: "Agovic, Sanimir" To: "gdb@sourceware.org" , "Jan Kratochvil (jan.kratochvil@redhat.com)" CC: "Boell, Keven" Subject: Variable Length Arrays (VLA) proposal Date: Fri, 28 Jun 2013 13:03:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-06/txt/msg00070.txt.bz2 Hello, FSF GDB is currently not able to evaluate Variable Length Arrays (VLA) for= =20 various languages e.g. Fortran and C. The root cause are dynamic values of= =20 attributes like length and bounds of array types (see dwarf4:2.19). On the archer project [1] VLA support was implemented by Jan Kratochvil and= is=20 known to be shipped with Fedora. This implementation hooks into check_typed= ef=20 and resolves the dynamic values to existing static attributes. However, thi= s=20 approach has some drawbacks, which are addressed in Jan's big plan for VLA = [1]. We've created three proposals, how VLA support can be added to FSF GDB. (1) Resolving check_typedef: This proposal is mainly based on Jan's proposal [2]. The function check_typedef does primary two things: it updates the passed t= ype=20 structure in terms of dynamic attributes, e.g. the size, bounds, etc. and i= t=20 creates a deep copy of the passed type, completes it and returns it to the= =20 caller. The function check_typedef will be called in the GDB code base befo= re=20 attributes of the type structure will be accessed. This should guarantee th= at=20 the type is up-to-date. However, the GDB code base is known that this funct= ion=20 call is also missed in some places, which may result in flaky behavior. The= type evaluation may or may not work. As check_typedef is a big monolithic functi= on it should be split into smaller parts, which are responsible for very specific= =20 tasks, e.g. calculating and updating the size of a type. By just splitting = the=20 function into several parts will not solve the primary check_typedef proble= m.=20 To solve this, almost all TYPE_* macros, which access potential dynamic=20 attributes, need to be changed in order to call the respective functions to= =20 calculate dynamic attributes instead of just accessing them statically. For= =20 calculating sizes and bounds the inferior memory is required. Thus the para= meter of most of the TYPE_* macros need to be changed from "struct type*" to=20 "struct value*", as "struct value*" contains the memory of the inferior as = well=20 as "struct type*". By changing the semantic of the TYPE_* macros, so called= =20 writer macros need to be introduced as some TYPE_* macros occur on the left= =20 side. E.g: TYPE_LENGTH(type) =3D 1; However, there is much risk for breaking things by changing most of the TYP= E_*=20 macros in combination with splitting check_typedef. By going this way the G= DB=20 mainline needs to be freezed at least for some days to get the changes into= the=20 repository once they are ready to avoid ending up in a merging disaster. Th= is is=20 because the changes are spread over the whole GDB source base. (2) Type normalization: This proposal is similar to Jan's approach [1] in transforming dynamic valu= es=20 of attributes into static ones: 1) resolve all dynamic attributes 2) create a copy of the type and assign the resolved attributes from step = 1) This proposal doesn't require to change check_typdef completely nor changin= g, the TYPE_* macros, which makes this solution very isolated and lean. Instead of hijacking check_typedef we hook into value_type() to normalize t= he=20 type. Since inferior types depend on a context - namely an address - to be= =20 resolvable this seems a good place to hook into. In addition all expression= =20 evaluations are routed via parse_and_eval() which returns a value, which ma= y be=20 associated with an address. Also the TYPE_* macros in gdbtypes.h could be l= eft=20 as-is. As a side effect gdb is now constantly creating types during the=20 normalization process and will increase the memory consumption constantly a= s=20 well. To avoid this behavior a garbage collector would be needed, which fre= es=20 the memory again when required. This could be done for example when GDB ret= urns=20 to its main loop. Nevertheless, such a garbage collector can result in a=20 performance overhead, which is expected to be very small. (3) Split struct type: The idea behind this proposal is to reflect the difference of types (dynami= c/ static attributes) in the type system used in GDB. At the moment we conside= r the=20 following types: - struct type Serves as a base. Certain properties are exposed using function point= ers=20 instead of raw attribute access e.g. length, bounds. - struct static_type Reassembles the functionality of the current struct type. It is used = for=20 types with statically values of attributes. - struct dynamic type Allows to express the dynamic values of attributes. Computation of le= ngth and bounds might be done lazily. - struct typedef_type A simple proxy type. Calls to length and bounds are forwarded to the= =20 underlying type. An implementation details which is left out is whether one would implement = it in=20 a OO style similar to breakpoint_ops. The main advantage is the increased maintainability of the type system itse= lf as=20 there would be a clear differentiation between static and dynamic types. Al= so=20 extensions and future requirements could be better addressed by simply=20 refactoring struct members into function pointers. The check_type function = could=20 be shortened, as function pointers will do the dynamic calculation work, an= d in=20 future steps completely removed by adding a function peel(), which would=20 recursively peel of any typedefs. This change would be rather large and wou= ld=20 affect many areas of GDB, like proposal (1). Summary: Proposal (1) would be very expensive and dangerous as the side effects of=20 resolving and removing check_typedef in one shot are not known. As a lot of= =20 macros have to be changed as well, the whole GDB code base will be affected= .=20 The implementation of proposal (2) would be very isolated and simple, but w= ill=20 leave the static attributes in struct type, which are actually dynamic.=20 Proposal (3) will make the type system of GDB more flexible, as differentia= ting=20 between static and dynamic types. Also it will calculate dynamic attributes= when they will be requested by the caller. However, also this change will be lar= ge as lots of GDB code need to be touched but it is the preferred proposal from o= ur side. We would appreciate your feedback and thoughts about the different proposal= s. -- Keven & Sanimir=20 [1] http://sourceware.org/gdb/wiki/ProjectArcher (branch archer-jankratochvil-vla) [2] http://sourceware.org/ml/gdb/2012-11/msg00094.html 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