Re: RFC: more detailed type information

[Greg Watson <g.watson@computer.org>]

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