From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10414 invoked by alias); 7 Feb 2002 00:24:08 -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 10293 invoked from network); 7 Feb 2002 00:24:04 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 7 Feb 2002 00:24:04 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16YcM5-00057K-00; Wed, 06 Feb 2002 19:24:01 -0500 Date: Wed, 06 Feb 2002 16:24:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sources.redhat.com, Jason Merrill Subject: Re: RFA: MI tests: tolerate prototypes Message-ID: <20020206192401.A19571@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , gdb-patches@sources.redhat.com, Jason Merrill References: <20020203210609.E5E035E9DE@zwingli.cygnus.com> <20020203180133.C26302@nevyn.them.org> <20020205202132.A17384@nevyn.them.org> <20020206004829.A1357@nevyn.them.org> <3C61C6EB.5060908@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C61C6EB.5060908@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00189.txt.bz2 On Wed, Feb 06, 2002 at 07:14:35PM -0500, Andrew Cagney wrote: > >Daniel Jacobowitz writes: > > > >>> Ah, by building `prototype'-style types for all the functions, even > >>> those declared without prototypes, and using the called-as types as > >>> the prototype argument types. It'll work because, even though the > >>> type claims to be prototyped, the argument types are such that we end > >>> up doing the same promotions required by the rules for calling > >>> non-prototyped functions. > > > >> > >>So, the question becomes - do we need MAYBE_PROTOTYPED? If we accept > >>that the types marked in stabs as parameters are promoted types, then > >>we can simply mark stabs functions as being prototyped, and trust > >>TYPE_FLAG_PROTOTYPED more than we do. > > > > > >If we do that, then: > >- Dwarf 2 will continue to work correctly, since its prototype info > > has always been accurate, > >- under STABS, calls to functions whose definitions we have debug info > > for will always work, unlike the current state of affairs, and > >- under STABS, calls via function pointers will do non-prototyped > > argument promotion, which is no worse than now. > > > >Sounds good to me. > > > >It does bother me, sort of on principle, that we won't really have > >info about which functions were declared in which way. I mean, > >prototypedness is a real property of function types in ISO C. But > >given that our debug format doesn't carry the info we need, I guess > >I'll just get over it. :) > > > Jim, my preference here is more along your proposal - have an explicit > ``prototype-unknown'' state. I don't think we need it. It seems that for at least stabs and DWARF-2 we have enough information to call the prototyped-ness known in all cases. In stabs we don't know if it is really prototyped or not, but we know the called-as type, which is close enough to a prototype for our purposes until debug info gets itself fixed. > From memory the last time this came up I also suggested here that > changing the default behavour across GDB is probably a good thing. I > don't think this is something that individual targets should be > deciding. Instead GDB should exibit consistent behavour across > host/target combinations, the decision being made on the basis of the > debug info. Certainly, it shouldn't be target-specific. It depends only on the debug format. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer