This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Add type support for Ada
- From: "Paul N. Hilfinger" <hilfingr at otisco dot mckusick dot com>
- To: jimb at redhat dot com
- Cc: ac131313 at redhat dot com, aidan at velvet dot net, drow at mvista dot com, per at bothner dot com, green at redhat dot com, muller at cerbere dot u- dot strasbg dot fr, gdb-patches at sources dot redhat dot com
- Date: Sat, 28 Sep 2002 02:25:59 -0700
- Subject: Re: [RFA] Add type support for Ada
- References: <20020926040044.I32211@velvet.net> <3D93C161.2070409@redhat.com> <vt2k7l7b46m.fsf@zenia.red-bean.com>
- Reply-to: Hilfinger at otisco dot mckusick dot com
> It looks to me as if the string cleanup stuff is distinct from the
> fixed instance stuff. These should be submitted as separate patches.
They definitely are logically separate changes.
> Is a `fixed instance' a feature of the language's type system itself?
> That is, is it something that an Ada programmer actually knows about?
> Or is it something used internally within GDB, or internally by some
> implementations of Ada?
It is not a language feature, but rather an optimization. The original
problem was that STABS and also GDB's internal type representation
was not adequate for representing "dynamic" Ada types---i.e., those that,
unlike C types, have data-dependent sizes. The scheme we hit on (in
retrospect perhaps not the best) was to encode a bunch of auxiliary
information into our type names, and to introduce additional types
carrying additional (encoded) information.
When Ada evaluation routines discover that a quantity has an encoded
type, they know to compute a conventional, fixed-sized GDB type based on the
data, and to attach this type to the value they are producing.
Unfortunately, the computations involved are expensive---involving type
lookups in some cases---and we don't want to repeat them unnecessarily.
Hence the flag.
> Should base_type use the tortoise-and-hare algorithm to detect cycles?
An interesting suggestion. However, there is at least one existing
place where GDB doesn't bother. Compare with the following (non-Ada-
related) code from evaluate_subexp_standard in eval.c:
/* get targettype of elementtype */
while (TYPE_CODE (check_type) == TYPE_CODE_RANGE ||
TYPE_CODE (check_type) == TYPE_CODE_TYPEDEF)
check_type = TYPE_TARGET_TYPE (check_type);
> When it detects a direct cycle, should it really just return the type,
> or should that be an internal error? When the base type of a range
> type is null, should that be an internal error?
Umm. Interesting questions. As I recall, I had the impression that
a self-referencing range type COULD occur legitimately, but given that was
4 years ago, my memory could be faulty. I suspect these tests were simply
bullet-(or segfault)-proofing. Replacing the NULL check at least with
an error would probably be a worthy experiment.
Paul