From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12421 invoked by alias); 25 Dec 2009 04:36:54 -0000 Received: (qmail 12412 invoked by uid 22791); 25 Dec 2009 04:36:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Dec 2009 04:36:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5F4592BABAE; Thu, 24 Dec 2009 23:36:46 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pBTXEiwhx-zg; Thu, 24 Dec 2009 23:36:46 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D0B382BABBD; Thu, 24 Dec 2009 23:36:45 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id BD11FF5939; Fri, 25 Dec 2009 05:06:46 +0100 (CET) Date: Fri, 25 Dec 2009 04:36:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFA/DWARF] Add DW_AT_GNAT_descriptive_type support Message-ID: <20091225040646.GY2788@adacore.com> References: <20091224180657.GV5942@adacore.com> <20091224193948.GA7936@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091224193948.GA7936@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2009-12/txt/msg00392.txt.bz2 > While it may make sense from the practical point of view I would like > a clear statement this is the reason for this "gross" > DW_AT_GNAT_descriptive_type code. I agree it is a bit gross. The problem is not technical difficulty; it's resources. I said, back in Apr (wow, so long ago already!): | At the time, we had hoped that this would be a temporary, local | change, until we find the time to work on generating pure DWARF. | But the reality is that we don't see this happening in the near | future. As we've come to accept this fact, we at AdaCore think | that it would be useful to others to be able to take advantage | of this attribute. | | The changes in GDB are relatively small, I think - at least in | the DWARF reader part. > With properly implemented DWARF-only DW_FORM_block* producer for GNAT > the GDB consumer would be IMO some small extension of dynamic types > (to accept DW_FORM_block* for several more DW_AT_* attributes and > reuse the existing dynamic->static converting code in check_typedef). The problem is that there are lots more situations where we would still need to fix GDB as well - as you have probably seen in the exp_dbug.ads spec. The record with a variable-length field is just one example. Another example would be a discriminated record, where certain components determine the contents of the rest of the record. Or arrays, where you need to access a parallel ___XA type. Etc. This is definitely something that AdaCore has been looking at - implementing the generation of proper dwarf. We looked at all the situations where an encoding was used, and how to replace it in DWARF. Apart from a few unknowns that have not be resolved yet, we more or less know how to express the rest. But this effort seems to be always stalled in favor of other, more urgent ones. It's an effort that is actually dear to me, since I very much dislike this encoding. But I don't want to start on this until I am done synchronizing the Ada mode at AdaCore and the Ada mode at the FSF. -- Joel