Re: dubious use of O_subtract in gas/config/tc-ia64.c

Re: dubious use of O_subtract in gas/config/tc-ia64.c

[Jan Beulich]

>> Could anyone shed some light on the relevance of the two instances
of
>> checks for O_subtract within operand_match(), cases
IA64_OPND_IMMU64,
>> IA64_OPND_IMM14, and IA64_OPND_IMM22?
>
>This code is present in the first check in, so it was probably needed
>for the linux kernel port.
>
>I see in your example that you are subtracting two symbols in
different
>sections, which isn't something that we can easily compute.

Even with the recent pcrel patch applied I still see problems with
this: The checks there prohibit more complex expressions than just a
simple subtract, e.g. (with symbol1 and symbol2 in the same section)

-(symbol1 - symbol2)
(symbol1 - symbol2) >> 4
(symbol1 - .) + (. - symbol2)

Of course, these examples may not look very meaningful by themselves,
but I think you get the point. Beyond that, pseudo opcodes like data4
and data8 deal with them without problem. It would seem to me (without
having it tried, yet) that maybe the original issue you saw when
removing these checks could be gone with the pcrel patch applied.

This isn't the end of problems, though: The way insn operands are
handled in general cause more problems when it comes to forward
references; the question here is perhaps also of more general (not just
IA64) nature: Shouldn't an operand that is supported by
.byte/.word/.long/.quad (and for IA64 their dataN equivalents) and that
would be valid as an insn operand also be accepted by that insn?

Jan

Re: dubious use of O_subtract in gas/config/tc-ia64.c

[James E Wilson]

On Mon, 2005-02-28 at 03:19, Jan Beulich wrote:
> Even with the recent pcrel patch applied I still see problems with
> this: The checks there prohibit more complex expressions than just a
> simple subtract, e.g. (with symbol1 and symbol2 in the same section)

Sure, the current O_subtract stuff has problems.  I didn't mean to
suggest it was correct.  I was just giving examples showing what the
original author was thinking.

Just removing the checks doesn't work.  We have to accept the operand,
and generate a reloc for it somehow.  I'm not sure what change you are
proposing.  I don't recall seeing a patch, and I am having trouble
coming up with one while I am sick.  I can do a test against the linux
kernel to make sure we aren't breaking it, but I need a patch to test.

There is one obvious difference between the data case and the
instruction case.  In the data case, we know the operand size.  In the
instruction case, we may not know the operand size.  If we have a
constant, we can know for sure whether an operand is OK, but if we don't
have a constant we have to guess.  We probably just have to accept
anything which isn't a constant, and then rely on later code that tries
to resolve relocations to give an error if appropriate.

A possible exception might be instructions with multiple operand sizes,
like move, in which case it might be useful to pick the large one, and
then relax to a smaller one.  Or maybe we just make it an error if movl
is required and the movl mnemonic wasn't used.  Your original example
seems to imply that you expect the latter case.

Also, we don't have PC-relative relocs for all instruction operand
sizes, which may constrain what we can do, but I don't know if that is
relevant to the immediate problem.  Presumably we just get an error when
resolving relocs which is what you expect.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: dubious use of O_subtract in gas/config/tc-ia64.c

[James E Wilson]

On Tue, 2005-02-01 at 06:46, Jan Beulich wrote:
> Could anyone shed some light on the relevance of the two instances of
> checks for O_subtract within operand_match(), cases IA64_OPND_IMMU64,
> IA64_OPND_IMM14, and IA64_OPND_IMM22?

This code is present in the first check in, so it was probably needed
for the linux kernel port.

I see in your example that you are subtracting two symbols in different
sections, which isn't something that we can easily compute.

If I write an example that subtracts two symbols in the same section,
then I get a reasonable result.  This testcase does not work if I
comment out the O_subtract checks.  Perhaps what we need is just a check
to verify that the symbols are in the same section?

        .data
bsym:   data8 0
esym:
        .text
start:
        mov             r1 = esym-bsym
        movl            r1 = esym-bsym

I tried a quick linux kernel build with a hacked assembler and found a
similar but slightly different testcase.  This occurs twice in the
arch/ia64/kernel/pal.S file.
        .text
1:
        adds r8 = 1f-1b,r8
1:

I didn't try looking for other examples.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

dubious use of O_subtract in gas/config/tc-ia64.c

[Jan Beulich]

Could anyone shed some light on the relevance of the two instances of
checks for O_subtract within operand_match(), cases IA64_OPND_IMMU64,
IA64_OPND_IMM14, and IA64_OPND_IMM22? I would suppose that because it is
explicitly getting special-cased there must be something I'm not seeing,
but to me it just seems to break things like

	.global esym
	.text
start:
	mov		r1 = esym-.
	movl		r1 = esym-.

which currently yields IMM22/IMM64 relocations (with strange addends)
instead of PCREL22/PCREL64I or at least a diagnostic.

Thanks, Jan