From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28541 invoked by alias); 28 Jan 2004 05:49:32 -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 28468 invoked from network); 28 Jan 2004 05:49:31 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 28 Jan 2004 05:49:31 -0000 Received: by zenia.home (Postfix, from userid 5433) id 1DBCD207A3; Wed, 28 Jan 2004 00:49:17 -0500 (EST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: handle zero-length types in value_from_register References: <40166B2D.9080506@gnu.org> <40166D8B.8030209@gnu.org> From: Jim Blandy Date: Wed, 28 Jan 2004 05:49:00 -0000 In-Reply-To: <40166D8B.8030209@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2004-01/txt/msg00717.txt.bz2 --=-=-= Content-length: 922 Andrew Cagney writes: > > Andrew Cagney writes: > > > >> > 2004-01-27 Jim Blandy > >> > * findvar.c (value_from_register): If the type has no length, > >> > just > >> > return an acceptable value --- don't report an internal error. > >> > > > > >> This looks to need a test case. > > I tried to put one together, but the bug only occurs when the > > zero-length value is allocated to a register. I couldn't find any way > > to make that happen at all. So the only known instance of this bug > > depends on bad debug info. > > The commentary should really reflect this important detail (also > mention the compiler that's broken for instance). Should GDB also > complain about the bogus info? Seems reasonable. I've attached a revision of the original patch, with an expanded comment, and a separate patch that makes GDB complain when it sees the bogus info. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=jimb.gdb-zero-length-type.patch Content-Description: tolerate reading zero-length values from registers Content-length: 2124 2004-01-27 Jim Blandy * findvar.c (value_from_register): If the type has no length, just return an acceptable value --- don't report an internal error. Index: gdb/findvar.c =================================================================== RCS file: /cvs/src/src/gdb/findvar.c,v retrieving revision 1.68 diff -c -r1.68 findvar.c *** gdb/findvar.c 26 Jan 2004 20:36:32 -0000 1.68 --- gdb/findvar.c 28 Jan 2004 05:47:05 -0000 *************** *** 617,623 **** struct value *v = allocate_value (type); CHECK_TYPEDEF (type); ! if (CONVERT_REGISTER_P (regnum, type)) { /* The ISA/ABI need to something weird when obtaining the specified value from this register. It might need to --- 617,646 ---- struct value *v = allocate_value (type); CHECK_TYPEDEF (type); ! if (TYPE_LENGTH (type) == 0) ! { ! /* It doesn't matter much what we return for this: since the ! length is zero, it could be anything. But if allowed to see ! a zero-length type, the register-finding loop below will set ! neither mem_stor nor reg_stor, and then report an internal ! error. ! ! Zero-length types can legitimately arise from declarations ! like 'struct {}'. GDB may also create them when it finds ! bogus debugging information; for example, in GCC 2.94.4 and ! binutils 2.11.93.0.2, the STABS BINCL->EXCL compression ! process can create bad type numbers. GDB reads these as ! TYPE_CODE_UNDEF types, with zero length. (That bug is ! actually the only known way to get a zero-length value ! allocated to a register --- which is what it takes to make it ! here.) ! ! We'll just attribute the value to the original register. */ ! VALUE_LVAL (v) = lval_register; ! VALUE_ADDRESS (v) = regnum; ! VALUE_REGNO (v) = regnum; ! } ! else if (CONVERT_REGISTER_P (regnum, type)) { /* The ISA/ABI need to something weird when obtaining the specified value from this register. It might need to --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=jimb.gdb-stabsread-check-for-undefined-types.patch Content-Description: check that forward reference type numbers are resolved Content-length: 2207 2004-01-27 Jim Blandy * stabsread.c (read_type): If we find any type numbers that are forward references, complain if the references aren't resolved by the time we're finished reading. (cleanup_undefined_types): Make error message more appropriate for a complaint. Index: gdb/stabsread.c =================================================================== RCS file: /cvs/src/src/gdb/stabsread.c,v retrieving revision 1.72 diff -c -r1.72 stabsread.c *** gdb/stabsread.c 19 Jan 2004 01:20:11 -0000 1.72 --- gdb/stabsread.c 28 Jan 2004 05:39:16 -0000 *************** *** 1446,1456 **** if (read_type_number (pp, typenums) != 0) return error_type (pp, objfile); - /* Type is not being defined here. Either it already exists, - or this is a forward reference to it. dbx_alloc_type handles - both cases. */ if (**pp != '=') ! return dbx_alloc_type (typenums, objfile); /* Type is being defined here. */ /* Skip the '='. --- 1446,1466 ---- if (read_type_number (pp, typenums) != 0) return error_type (pp, objfile); if (**pp != '=') ! { ! /* Type is not being defined here. Either it already ! exists, or this is a forward reference to it. ! dbx_alloc_type handles both cases. */ ! type = dbx_alloc_type (typenums, objfile); ! ! /* If this is a forward reference, arrange to complain if it ! doesn't get patched up by the time we're done ! reading. */ ! if (TYPE_CODE (type) == TYPE_CODE_UNDEF) ! add_undefined_type (type); ! ! return type; ! } /* Type is being defined here. */ /* Skip the '='. *************** *** 4197,4203 **** default: { complaint (&symfile_complaints, ! "GDB internal error. cleanup_undefined_types with bad type %d.", TYPE_CODE (*type)); } break; --- 4207,4214 ---- default: { complaint (&symfile_complaints, ! "forward-referenced types left unresolved, " ! "type code %d.", TYPE_CODE (*type)); } break; --=-=-=--