This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] ia64 unwind directive semantics
- From: James E Wilson <wilson at specifixinc dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 11 Feb 2005 11:49:29 -0800
- Subject: Re: [PATCH] ia64 unwind directive semantics
- References: <s20ca004.024@emea1-mh.id2.novell.com>
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