From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6649 invoked by alias); 1 Dec 2001 23:48:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6628 invoked from network); 1 Dec 2001 23:48:52 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by hostedprojects.ges.redhat.com with SMTP; 1 Dec 2001 23:48:52 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 399ED3DF1; Sat, 1 Dec 2001 18:48:51 -0500 (EST) Message-ID: <3C096C63.10209@cygnus.com> Date: Sat, 01 Dec 2001 15:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: maybe prototyped References: <20011128045247.2ABFF5E9D8@zwingli.cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00010.txt.bz2 > In light of the recent discussion about stabs lossage with regards to > prototyped functions, here's something that actually allows the debug > readers to convey the depth of their convictions to the argument > promotion code. > > Is this a wise idea? Who knows? It does get rid of a FIXME, though. > > 2001-11-27 Jim Blandy > > Allow debug readers to indicate that a function type may or may > not be prototyped. > * gdbtypes.h (TYPE_FLAG_MAYBE_PROTOTYPED): New flag. > (TYPE_FLAG_INCOMPLETE, TYPE_FLAG_CODE_SPACE, > TYPE_FLAG_DATA_SPACE): Renumber. > * stabsread.c (define_symbol): Mark all function types as `maybe > prototyped', except those that have prototype info, which we > continue to mark as `prototyped'. > * valops.c (value_arg_coerce): Change third argument to indicate > whether the function is definitely prototyped, definitely not > prototyped, or perhaps prototyped. Only consult > COERCE_FLOAT_TO_DOUBLE when they are perhaps prototyped. > (hand_function_call): Call value_arg_coerce appropriately. > One thought on the name. Would ``unknown'' be a better mental que than ``maybe'' - whereabouts unknown, prototype unknown. The other on the macro definition (notes on a discussion we had). There are are only three possabilities for the floating point arguments: o coerced o not co-erced o unknown and that is strictly determined from the debug info (and language?). The problem is that many architectures have ignored this and instead instead made somewhat arbitrary decisions to always/never promote (well probably based on the debug info known to be used for the particular host). Would it be better to de-multi-arch COERCE_FLOAT_TO_DOUBLE and instead move the code making this decision to one place - that way the decision was made strictly on the basis of the type/debug information? This is a pretty significant change since it would mean that, for some targets, GDBs behavour might change :-/ Against that, however, is the benefit of finally making GDB's behavour consistent and predictable across all architectures. Personally, I think the need for consistency and predictability is more important in this case. We could always add a command that revers GDB to the old behavour (or forces a particular behavour for the unknown case). Food for thought ... Andrew