From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21727 invoked by alias); 7 Jan 2003 18:16:19 -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 21718 invoked from network); 7 Jan 2003 18:16:15 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 7 Jan 2003 18:16:15 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18W09Q-0006K2-00; Tue, 07 Jan 2003 14:16:40 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18VyGy-0006He-00; Tue, 07 Jan 2003 13:16:20 -0500 Date: Tue, 07 Jan 2003 18:16:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: Slay COERCE_FLOAT_TO_DOUBLE Message-ID: <20030107181620.GA24050@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20021223203031.GA18990@nevyn.them.org> <3E1A0655.2050009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1A0655.2050009@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00289.txt.bz2 On Mon, Jan 06, 2003 at 05:42:29PM -0500, Andrew Cagney wrote: > >Stabs compilers (I only checked GCC and Sun Workshop CC, but those are the > >two major ones) emit the call-as type in the debug information. I.E. an > >unprototyped function taking a float argument will have a type signature > >that says it takes a double. So the easy thing to do for stabs is to set > >TYPE_FLAG_PROTOTYPED always, with appropriate commentary. I've done this. > >It caused a minor bit of testsuite churn, since some ()'s became (void)'s; > >I > >think that's OK, we know they are really void functions anyway. > > Can you expand a bit here. When exactly do the () become (void)? > Looking at the changes to stabs, mdebug and hpread it appears to reverse > the default for all non dwarf* cases - assume prototyped rather than > un-prototyped? That's a pretty radical change and needs to be clearly > spelt out in at least the NEWS file. > > (Like many people I'm back from a break and am only just getting to > these e-mails. This is probably why there were few responses earlier.) I did explain this but I wasn't quite verbose enough, in the paragraph above and several others in the message you're quoting. Let me try to be more thorough. * DWARF, DWARF-2: unchanged * stabs: all functions are now marked prototyped. This is consistent with the debugging information emitted by Sun CC and by GCC. The type emitted is only the correct way to call the function _if_ you assume that it is a prototyped declaration. It's a call-as type, not a declared-as type. Treating it like a prototype gives us the correct behavior. * mdebug, hpread: All non-C functions are marked as prototyped Only C of the languages supported on these targets supports non-prototyped functions. This does _not_ change current behavior because they acheived a similar hack in their coerce methods. The only change is that some functions _whose signature we know to have no arguments_ are now printed as foo(void) instead of foo(). That and COERCE_FLOAT_TO_DOUBE are what we used TYPE_FLAG_PROTOTYPED for. It's not a change of general impact; I'm only talking about some code in the type pretty-printer. For C the "assume un-prototyped" behavior was left intact, not radically changed. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer