Re: open ia64 issues

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

On Mon, 2005-02-14 at 01:37, Jan Beulich wrote:
> before (for which I'm in the process of creating a fix), I currently see
> two open issues, addressing of which however seems to be more intrusive
> so I'd like to check whether there are objections to fix these prior to
> starting to work on them:

There has been a bit of talk about making a branch for the binutils-2.16
release.  If we know that we need an intrusive change, it should
probably wait until after the branch is made.  That would give us
roughly a year to work out problems before it appears in an official
release.  It would also avoid unnecessary delays with the binutils-2.16
release.  There might be an issue if HJ tries to create a release from a
snapshot of mainline, but that would be HJ's problem.

> opcodes or directives), but not in labels. The latter also implies that
> you cannot use un-suffixed reserved symbols in directives (i.e. .global
> @pause ought to be invalid).

I don't see how this follows from what you said.  However, in the
section on name spaces, it says that a symbol can not occur more than
once in any name space, and in the section on symbols, it says things
like @pause are reserved symbols.  That means that both .global @pause
and .global @pause# should be invalid.

If we do have to change how directives work, then we could always add
them to md_pseudo_table in tc-ia64.c to avoid changing common code. 
This might create long term maintenance problems though, as then
tc-ia64.c would have to change every time the list of supported
directives changed, which would be a hassle.  Not clear if this is a
better solution.

It isn't clear why we can't just change ia64_canonicalize_symbol_name to
reject reserved symbol names.  That seems like a simpler solution, and
no less efficient.  Hmm, the new @mutex, @clear, and @imply reserved
names probably need to be put into the pseudo_func array to make this
work.  The rest of the @ reserved words should already be in there.

I agree that accepting more than one # operator is invalid.  I doubt
that anyone is relying on this gas behaviour.

If we really do need invasive changes to get this right, it isn't clear
whether it is worth the trouble.  

> efficient addp4) it would be necessary to weaken the rejection of
> 'orphan' qualifying predicates:

The asm language manual does allow newline white space in between a qp
and an instruction mnemonic, so this is something we should accept.

The issue here is making sure that we don't accept something like
	(p1)
label:
	mov r1 = r2
If anything other than an instruction mnemonic follows a qp, then we
have to reject it.  Unfortunately, labels get parsed in machine
independent code, so there is no obvious easy way to give an error for
this case.  It was just easier to handle this by giving an error if we
still have an unused qp at the beginning of a line.

There are also some parsing difficulty with the ;; stop bit and tags,
but since we use tricks to handle them in the tc-ia64.c file, we should
be able to give errors for them easily.  So
	(p1)
	;;
needs an error check which is trivial, and we already give an error for
	(p1)
	[debug:]

We also need to worry about directives here.
	(p1)
	.directive
should be an error also.  That one is probably just as tricky as getting
the label case right.

This stuff is probably easy for IAS as their asm parser understands the
form of IA-64 assembly code, whereas our target independent parser
doesn't.  Maybe some hooks can be added to the parser to support the
IA-64 specific tags and qps?

Now that you made me think about this, I remembered that we handle tags
wrong also.  A tag is only legal as part of an instruction statement,
which means all of the above examples are also invalid if you replace
the qp with a tag, but we don't warn for any of them.  Fixing gcc to
place the tags in the proper place will be a bit of work, which means we
probably can't fix this part of gas anytime soon.  This came up recently
on the gcc list.  That was even a thread that you started.
	http://gcc.gnu.org/ml/gcc/2005-01/msg01398.html
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com