From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27148 invoked by alias); 16 Sep 2011 14:57:03 -0000 Received: (qmail 27140 invoked by uid 22791); 16 Sep 2011 14:57:03 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Sep 2011 14:56:43 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8GEugME015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 10:56:42 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8GEueAB012914; Fri, 16 Sep 2011 10:56:41 -0400 From: Phil Muldoon To: Paul Koning Cc: gdb-patches@sourceware.org Subject: Re: Python: add field access by name and standard python mapping methods to gdb.Type References: <0A6582A5-22D0-4284-AE41-DE92F544B650@comcast.net> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Fri, 16 Sep 2011 14:57:00 -0000 In-Reply-To: <0A6582A5-22D0-4284-AE41-DE92F544B650@comcast.net> (Paul Koning's message of "Fri, 16 Sep 2011 10:54:50 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00307.txt.bz2 Paul Koning writes: > On Sep 16, 2011, at 6:45 AM, Phil Muldoon wrote: > >> Paul Koning writes: >> >>> ... >> >>> +typy_getitem (PyObject *self, PyObject *key) >>> +{ >>> + struct type *type = ((type_object *) self)->type; >>> + char *field; >>> + int i; >>> + >>> + field = python_string_to_host_string (key); >>> + if (field == NULL) >>> + return NULL; >>> + >>> + /* We want just fields of this type, not of base types, so instead of >>> + using lookup_struct_elt_type, portions of that function are >>> + copied here. */ >>> + >>> + for (;;) >>> + { >>> + CHECK_TYPEDEF (type); >>> + if (TYPE_CODE (type) != TYPE_CODE_PTR >>> + && TYPE_CODE (type) != TYPE_CODE_REF) >>> + break; >>> + type = TYPE_TARGET_TYPE (type); >>> + } >> >> This gives me pause, not because it is wrong, but because I wonder if >> there is a possibility that this loop will never exit. I presume it >> will eventually find the base_type, just by continually walking the >> TARGET_TYPE until it reaches bottom. >> >> Can you check how this is done in other parts of GDB (this must happen >> quite often?). > > This code was directly lifted from lookup_struct_elt_type in gdbtypes.c The same sort of thing occurs in a number of other places, as you expected. For example, in c_value_of_variable in varobj.c, a similar loop shows up but that one just strips TYPE_CODE_REF, it does not look for TYPE_CODE_PTR. > > I can certainly make this a standard function, perhaps in gdbtypes.c. Then I can also change other occurrences of this code pattern to call that, but I would not want to go use it for things that are similar but not identical (like the one in varobj.c I mentioned). Should that be a separate patch? It seems better that way. > > paul Yeah that is fine. Thanks for checking! Cheers Phil