Re: [PATCH] ia64 unwind directive semantics

[James E Wilson <wilson@specifixinc.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