Re: PATCH: Don't allow ia64 unwind section to point to section indifferent files

[James E Wilson <wilson at specifixinc dot com>]

On Tue, 2005-05-17 at 15:13, H. J. Lu wrote:
> 	* config/tc-ia64.c (unwind): Add proc_start_addr.
> 	(dot_proc): Set unwind.proc_start_addr to expr_build_dot ().
> 	(dot_endp): Use unwind.proc_start_addr instead of
> 	unwind.proc_start for unwind info.

This is an easy obvious way to get the dot value back, but this is
undoing a change that Jan had deliberately made.  So we shouldn't be
doing this without talking to Jan and/or re-reading the original thread
to make sure this is OK.  Otherwise, we are just trading one problem for
another.  I see no attempt to do any of this.

The original thread starts here:
    http://sourceware.org/ml/binutils/2005-01/msg00380.html
and there is a follow up thread here:
    http://sourceware.org/ml/binutils/2005-01/msg00476.html
This issue of using dot vs the function symbol name was discussed,
because I pointed it out and said I wasn't sure it was safe, and Jan
answered that it was necessary for ias compatibility.

The basic question here is whether it is ever OK for anything to come
between the .proc and the function label.  Personally, I think that
IA-64 assembly is complicated enough that we should only ever accept
strictly formatted assembly code, in which case no data allocation or
stray instructions are allowed after the .proc and before the function
label.  Apparently, ias supports other stuff here.  If we do take a
strict approach, then we should perhaps be emitting warnings or errors
when we see code that doesn't meet our strict requirements, instead of
silently generating object files with bad unwind info.  A strict
approach also means things like switching sections inside a function are
forbidden.

There is also a complication here with function with alternate entry
points, as an alternate entry point could perhaps come before the
function label, in which case using dot is perhaps better than using the
function label, though Jan seems to argue the other way.

Anyways, if Jan has no objection to this change, then it is OK with me
too.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com