From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22787 invoked by alias); 4 Mar 2004 09:58:14 -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 22771 invoked from network); 4 Mar 2004 09:58:11 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 4 Mar 2004 09:58:11 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id i249v323006169; Thu, 4 Mar 2004 09:57:18 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i249umg26863; Thu, 4 Mar 2004 09:56:48 GMT Message-ID: <200403040956.i249umg26863@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Mark Kettenis cc: rearnsha@arm.com, drow@false.org, gdb-patches@sources.redhat.com Reply-To: Richard Earnshaw Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [rfa/arm] Fix some structs.exp failures In-reply-to: Your message of "Wed, 03 Mar 2004 22:34:52 +0100." <200403032134.i23LYqYD001561@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-03/txt/msg00068.txt.bz2 Message-ID: <20040319000900.Yz3NqXAdKMtzb_6EoiuXJuSa-EpwuRmvr1sY5gofAyY@z> > check_typedef is completely > undocumented -- no mention in the internals documentation, and not even a > comment in gdbtypes.[ch]. > > There is one comment about check_typedef()/CHECK_TYPEDEF() in > gdbtypes.h. Anyway, Daniels fix is OK. Before you look at a type the > way arm_use_struct_convention does, you should have called > check_typedef(), otherwise you'll look at the typedef itself, and not > its underlying type. > I guess if you call a comment on an (apparently) unrelated macro 400 lines earlier in the file documentation then I was wrong. However, that still begs a load of questions: What are the input parameters? What is returned? What is it safe to pass? Can it be called more than once? Does it operate recursively? Does it change the input parameter, or is a new object created? Some of these may be obvious from analysing the source, but that shouldn't really be necessary. R.