From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4413 invoked by alias); 29 Mar 2006 00:18:26 -0000 Received: (qmail 4404 invoked by uid 22791); 29 Mar 2006 00:18:26 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-junco.atl.sa.earthlink.net (HELO elasmtp-junco.atl.sa.earthlink.net) (209.86.89.63) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Mar 2006 00:18:25 +0000 Received: from [68.166.114.35] (helo=[Ap@IPv6:::1]) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FOOOD-0004nw-LP; Tue, 28 Mar 2006 19:18:22 -0500 In-Reply-To: References: <20060328223609.GD11817@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C1CE32A-A819-4150-B6E6-7F27120B2A92@computer.org> Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Greg Watson Subject: Re: RFC: more detailed type information Date: Wed, 29 Mar 2006 00:54:00 -0000 To: Greg Watson X-ELNK-Trace: b18dadd04c208faa1aa676d7e74259b7b3291a7d08dfec7956284bd0a1f4916d0490c8e35b7d9909350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00336.txt.bz2 On Mar 28, 2006, at 4:50 PM, Greg Watson wrote: > > On Mar 28, 2006, at 3:36 PM, Daniel Jacobowitz wrote: > >> On Thu, Mar 09, 2006 at 12:49:23PM -0700, Greg Watson wrote: >>> I'm using Eclipse as a front-end for gdb, but I need to be able to >>> get more detailed type information than is currently possible. This >>> is required in order to provide more sophisticated functionality >>> than >>> just displaying the type and value as strings. >> >> Hi Greg, >> >> Can you be a little more detailed about what you need from GDB? >> There've been several mentions of this functionality recently, >> and I'm nearly positive that Apple's GDB supports something similar, >> so it's clearly a good idea. However, what you have is a very thin >> layer around GDB's type system, which makes it hard to change the >> type >> system at all without simultaneously changing the MI interface. I'd >> like to know what information is really useful. >> >> With C, of course, it doesn't much matter: the underlying type system >> can be simple because the language type system is simple. But with >> other supported languages this can be much harder. >> >> And, no offense, but the ref=/seen= interface is nasty! Maybe we >> should give types session UIDs. >> > > Hi Daniel, > > What I'm after is a language independent type description that > provides enough information to allow the manipulation of program > data in an external framework. For example, I'd like to be able to > compare (subtract) all the elements of two arrays of floating point > numbers. I have already implemented this infrastructure for type > and value representation, but it's limited by the information that > can be obtained via the current MI interface. Since gdb maintains > this type information internally, I was hoping to provide a more > complete, efficient, and language independent means of accessing > the information. > > The information that I need includes the endianness and size of > simple types, and the type description and layout of complex types. > While the representation I'm using is not a complete one-to-one > mapping with the memory layout in the target (I don't preserve > padding in structures for example) it is a fairly accurate > representation of the object. Currently I support all C and Fortran > types, a subset of C++ (I'm only interested in data, so methods and > virtual types are not currently implemented), Pascal strings, and a > few other odds and ends. Adding support for a new type is not > particularly difficult. > > I'd be very happy with a gdb interface that prints the type > description directly in my format :-) I actually wrote the code to > do this a few years ago but I thought this would not be of interest > to others, which is why I was suggesting using the gdb type > descriptions. Are you expecting the type system to change? I've > been working with gdb for many years and, apart from new language > features, there seems to have been little change in this area. > > I wasn't aware that the Apple GDB supported something like this. > I'll take a look to see if it could provide the information I'm > after. Would this be a more acceptable way to go? > > LOL, I don't have any attachment to the ref/seen interface. If you > can think of a better way to deal with recursive type definitions, > I would love to know! > > Regards, > > Greg > > Daniel, Just a quick followup. I've taken a look at the Apple changes to the MI code. It appears they have (amongst other things) added a 'typecode' value to the -var-create and -var-list-children commands. This typecode is a direct translation of the GDB typecode into a string (TYPE_CODE_ARRAY -> 'ARRAY', etc.), and would make it somewhat easier to obtain type information. It still necessitates many MI commands to obtain a complex type description, however, nor does it appear to be possible to obtain length and/or byte ordering information. The additional level of information provided by Apple would definitely be beneficial, but for my purposes a recursive type description would still be the most preferable way to go. Regards, Greg