From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20673 invoked by alias); 11 Feb 2005 19:49:34 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 20648 invoked from network); 11 Feb 2005 19:49:30 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 11 Feb 2005 19:49:30 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 75F7F16A47; Fri, 11 Feb 2005 11:49:29 -0800 (PST) Subject: Re: [PATCH] ia64 unwind directive semantics From: James E Wilson To: Jan Beulich Cc: binutils@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1108151369.19527.24.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Fri, 11 Feb 2005 23:15:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00263.txt.bz2 On Fri, 2005-02-11 at 04:08, Jan Beulich wrote: >Indeed. What lead me to think these aren't, despite their name, >stack-like was the fact that dot_alias, in its error path, has two >invocations of obstack_free; according what you say (the later) one >should be sufficient there... Yes, an oversight. We only need one obstack_free call here. > >If we want to be able to free these strings here, then we can't use > >obstack to allocate them. > Perhaps we should. Or, alternatively, we can use a different obstack than notes. If we have an obstack used for dot_rot only, then we know that it will be save to free everything, and we can do it with one obstack_free call. > >This one is safe, because we know that there are no other allocations > on > >the notes obstack since this string was allocated. > After you stated the above, it would seem to me that this isn't safe > either, because there is another (conditional allocation inbetween). > Thus the order of these two needs to be changed. If hash_insert fails, then dr did not get allocated to the hash table, and hence it is OK to free it. However, looking again, I do see that there is a possible problem with a dangling pointer. I believe we can fix that by moving the "drpp = &dr->next;" assignment after the hash_insert if statement, and putting "*drpp = NULL;" inside the if statement. Your solution of allocating name after dr is also acceptable. > * config/tc-ia64.c (dot_rot): Add comment that name strings > should > be freed when wiping out previous state. Canonicalize names > before > use. ... Thanks. This is OK. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com