This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: open ia64 issues


>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.

OK, then I'll put this on my mid-term todo list. Once the branch is done (and I have time), I'll see how invasive the change would be.

>> 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.

That's at least not the way ias seems to behave; I don't think separating register and symbol name spaces makes a lot of sense, and from ias behavior it doesn't seem like they do it.

>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.

I was specifically intending to avoid this, for exactly these foreseeable maintenance problems.

>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.

It could reject reserved symbols, but as I said above that's not how ias appears to behave; instead the # operator seems to be taken as an escape from the reserved set of symbols (not from the register name space, since otherwise you had no way to refer to registers defined through .rotX and colliding with predefined register names; see the pound testcase, which works fine with ias).
However, the current way ia64_canonicalize_symbol_name gets used is improper for another reason, which I tried to point to before., but perhaps wasn't clear enough: This gets called (a) perhaps multiple times on a symbol and (b) regardless of whether the symbol appeared as an operand or a label.

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

Right. But it doesn't know about macros, so the effect of a (qp) followed by a macro invocation can't be defined there. We need to try to make the most sense of it. What I'd like to see is that the (qp) applies to all instructions generated by the macro (provided the expansion contains nothing disallowing the (continued) use of a (qp), like as you point out a label, tag, or stop, and of course no other (qp); I'm not sure whether directives should generally be excluded here, I would think only those that can alter the current location should be * exclusion of conditionals would be especially bad).

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]