From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 778 invoked by alias); 4 Jan 2003 17:33:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 769 invoked from network); 4 Jan 2003 17:33:25 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 4 Jan 2003 17:33:25 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Uu3F-0004kP-00; Sat, 04 Jan 2003 13:33:45 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UsAj-0002qf-00; Sat, 04 Jan 2003 12:33:21 -0500 Date: Sat, 04 Jan 2003 17:33:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com, jimb@redhat.com Subject: Re: Replace TYPE_FLAG_PROTOTYPED with two flags Message-ID: <20030104173321.GA10872@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb@sources.redhat.com, jimb@redhat.com References: <200301041712.h04HCrw01931@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301041712.h04HCrw01931@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00043.txt.bz2 On Sat, Jan 04, 2003 at 11:12:53AM -0600, Michael Elizabeth Chastain wrote: > I've got these FAILs with gcc -gdwarf-2, both v2 and v3: > > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2) > FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765) > > This happens because t_float_values has no prototype. The dwarf2 reader > leaves TYPE_FLAG_PROTOTYPED clear, but later on, value_arg_coerce refuses > to trust the flag and guesses. > > Indeed, Jim Blandy has been down this path recently: > > http://sources.redhat.com/ml/gdb-patches/2001-11/threads.html#00529 > > I am writing a new patch ("six weeks in the laboratory can often save > fifteen minutes in the library"). Instead of TYPE_FLAG_PROTOTYPED and > TYPE_FLAG_MAYBE_PROTOTYPED, I use a more solid model: > > TYPE_FLAG_PROTO_KNOWN gdb knows whether there is a prototype > > TYPE_FLAG_PROTO_YES if proto_known is true, says whether there is > a prototype > > The dwarf and dwarf-2 readers always set TYPE_FLAG_PROTO_KNOWN, > and may set TYPE_FLAG_PROTO_YES. > > The stabs reader sets TYPE_FLAG_PROTO_KNOWN when it finds an actual > prototype (an argument list in the stabs). This does not happen with > gcc, but the comments say that it can happen with sun cc. > > My big question here is: is it safe to assume that dwarf and dwarf-2 > have accurate prototype information? That is, if there is no prototype > in the debug information, can gdb really be sure that the function has > no prototype and then rely on that information? Yes, it is. GCC honors DW_AT_prototyped. > My testing says that it can, for dwarf-2. I haven't tested dwarf yet. > (dwarf might hit the OBSOLETE list some day but it's not OBSOLETE yet). > The stabs+ case still works because TYPE_FLAG_PROTO_KNOWN==0 behaves > like the existing code. > > If it's safe to make this assumption, then I would like to proceed with > my patch, because this fixes a real bug with dwarf-2. My goal here is > to fix bugs where dwarf-2 behaves worse than stabs+. I suggest reading the more recent archives before you do this. Particularly: 347 N F 12/23 To gdb-patches@ ( 44K) RFC: Slay COERCE_FLOAT_TO_DOUBLE 348 N T 12/24 Eli Zaretskii (0.7K) `-> the which I was planning on committing this afternoon, since it received no comments to the contrary, and that's what I said I would do when I posted it. It will fix the same problem. I took a different approach than you did, as described in that message; it's a little less cautious, but more flexible. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer