From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7685 invoked by alias); 26 Jun 2009 17:12:54 -0000 Received: (qmail 7674 invoked by uid 22791); 26 Jun 2009 17:12:54 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 17:12:45 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5QHCZNX364578 for ; Fri, 26 Jun 2009 17:12:35 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5QHCZqI3289292 for ; Fri, 26 Jun 2009 19:12:35 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5QHCYBi026272 for ; Fri, 26 Jun 2009 19:12:35 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n5QHCXOh026222; Fri, 26 Jun 2009 19:12:33 +0200 Message-Id: <200906261712.n5QHCXOh026222@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 26 Jun 2009 19:12:33 +0200 Subject: Re: [patch] [3/5] Types reference counting [make_function_type-objfile] To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Fri, 26 Jun 2009 17:12:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com (Tom Tromey), gdb-patches@sourceware.org In-Reply-To: <20090626163927.GA14063@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Jun 26, 2009 06:39:27 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00745.txt.bz2 Jan Kratochvil wrote: > > Also, I think the implementation is broken in the "type smashing" case: > > if there is an incoming type allocated in objfile A, but the argument to > > make_function_type specifies objfile B, > > I do not think it can happen. So far always type A referencing -> type > B either had the same TYPE_OBJFILE or TYPE_OBJFILE(B) was NULL. Using such > assertion-checks without facing problems. > > As there cannot be a DWARF reference across objfiles (there can be one just > across CUs) cross-file type references use TYPE_IS_OPAQUE and they get > resolved each time on dereferencing such reference by calling check_typedef. Yes, there is no current usage of the make_function_type interface that does this, and it would indeed be broken. I guess was I was trying to say is that the new interface that allows to specify an objfile independently of the target type may appear to invite such incorrect usage ... But in either case, I agree this should be prevented by assertion checks. > > Therefore, I'd prefer to fix the two problems mentioned above, and then > > revert your patch. > > If the current rule: > # So far always type A referencing -> type B had either the same TYPE_OBJFILE > # or TYPE_OBJFILE(B) was NULL. > > will be changed to: > # Type A referencing -> type B had the same TYPE_OBJFILE. Mostly. We still can have the case were TYPE_OBJFILE(A) is NULL but TYPE_OBJFILE(B) is non-NULL, for example where A is a temporary array and B the element type. The way I see the invariant is If Type A references Type B *and* A is objfile-associated *then* B must be associated to the same objfile > I only welcome it and sure I agree with reverting my patch afterwards. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com