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

["H. J. Lu" <hjl@lucon.org>]

On Tue, May 17, 2005 at 04:20:47PM -0700, James E Wilson wrote:
> 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.

I am checking with icc/ias people to see if we can find a common
approach.


H.J.