From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16737 invoked by alias); 28 Sep 2002 09:24:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16729 invoked from network); 28 Sep 2002 09:24:49 -0000 Received: from unknown (HELO otisco.McKusick.COM) (209.31.233.190) by sources.redhat.com with SMTP; 28 Sep 2002 09:24:49 -0000 Received: (from hilfingr@localhost) by otisco.McKusick.COM (8.9.3/8.9.3) id CAA10025; Sat, 28 Sep 2002 02:25:59 -0700 Date: Sat, 28 Sep 2002 02:24:00 -0000 Message-Id: <200209280925.CAA10025@otisco.McKusick.COM> X-Authentication-Warning: localhost.localdomain: hilfingr set sender to hilfingr@otisco.mckusick.com using -f From: "Paul N. Hilfinger" To: jimb@redhat.com CC: ac131313@redhat.com, aidan@velvet.net, drow@mvista.com, per@bothner.com, green@redhat.com, muller@cerbere.u-.strasbg.fr, gdb-patches@sources.redhat.com In-reply-to: (message from Jim Blandy on 27 Sep 2002 14:52:49 -0500) Subject: Re: [RFA] Add type support for Ada Reply-to: Hilfinger@otisco.mckusick.com References: <20020926040044.I32211@velvet.net> <3D93C161.2070409@redhat.com> X-SW-Source: 2002-09/txt/msg00699.txt.bz2 > 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