From: Greg Watson <g.watson@computer.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: more detailed type information
Date: Wed, 29 Mar 2006 00:20:00 -0000 [thread overview]
Message-ID: <BA309141-3AB8-477A-BF92-47222B8819E9@computer.org> (raw)
In-Reply-To: <20060328223609.GD11817@nevyn.them.org>
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
next prev parent reply other threads:[~2006-03-28 23:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-09 20:20 Greg Watson
2006-03-28 23:50 ` Daniel Jacobowitz
2006-03-29 0:20 ` Greg Watson [this message]
2006-03-29 0:54 ` Greg Watson
2006-04-06 6:34 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BA309141-3AB8-477A-BF92-47222B8819E9@computer.org \
--to=g.watson@computer.org \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox