Re: PATCH: PR gas/10704: as segfault in memory lookup intel syntax

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Oct 01, 2009 at 07:47:57PM -0700, H.J. Lu wrote:
> PR 2117 was caused by:
> 
> http://sourceware.org/ml/binutils/2005-12/msg00001.html

I've done some more analysis.  I think this patch merely exposed the
real cause, bugs in tc-ia64.c.  As I see it, expression_and_evaluate
is supposed to be used where you need the value of an expression right
away.  Good examples of correct uses are those in cond.c, as.c,
read.c:get_absolute_expression, and read.c:s_lsym.  The one in
read.c:s_reloc is wrong.

If you take a look at what happens with the ltoff22x-2.s testcase,
you'll see that the "foo#" in "addl r3 = @ltoffx(foo#), gp" is read
via a plain expression() call in ia64_parse_name.  The "foo#" in
"ld8.mov r3 = [r3], foo#" however is read via expression_and_evaluate()
in tc-ia64.c:parse_operand.  That is why the first "foo#" remains as a
reference to "foo#" while the second references the equate, "bar#", if
you remove the fix for PR2117.  Modifying expression_and_evaluate for
the sake of ia64 is likely to break some other use;  Certainly that's
what happened with every change I tried.

So it seems to me that tc-ia64.c must not use expression_and_evaluate
anywhere a relocation against a symbol might be emitted.  However,
tc-ia64.c:parse_operand is also used in many other contexts where we
probably *should* be using expression_and_evaluate, for example when
reading register names.  I don't know ia64 assembly well enough to
sort this all out myself.

What this means for the release is that PR10704 is currently open.  If
I'm not mistaken, this bug affects all targets.  As the submitter
says, HJ's  attempted fix doesn't cure the problem.  The only solution
I see is to revert HJ's PR2117 patch and fix the ia64 backend.

-- 
Alan Modra
Australia Development Lab, IBM