Arm64: assembling adrp with operand involving .

[Nick Clifton]

Hi Jan,

> I would expect these two
> 
> 	adrp	x0, .
> 1:	adrp	x0, 1b
> 
> to assemble to the same encoding with similar attached relocations.

Me too.

> The first, however, appears to have evaluation of . deferred until the
> end of assembly, i.e. the resulting operand depends on the number of
> subsequent insns in the same source file. At a guess this is fallout
> from eac4eb8ecb26 "Fix a problem assembling AArch64 sources when a
> relocation is generated against a..." (for some reason the title is
> truncated).

That is because I put the rest of the description on a second line, sorry.
The second line reads:

  generated against a symbol that has a defined value.

The patch was created as a fix for PR 27217.

>  According to my observations other insns aren't affected,
> yet the change to parse_adrp() doesn't really stand out in said commit.
> Hence I'm neither really certain that's the one, nor how a possible fix
> could look like. Do you have any thoughts?

Well the change added a new argument to the ...get_expression() function,
so all callers were updated.  There was no specific intention to change
parse_adrp for some other reason.

Anyway - this does look like a bug, although I think that it might be
restricted to just an unadorned reference to dot.  ie:

   adrp	x0, .
   1:	adrp	x0, 1b
   adrp	x0, . - 8

When assembled and then dumped, gives:

0000000000000000 <.text>:
    0:	90000000 	adrp	x0, 0 <.text>
			0: R_AARCH64_ADR_PREL_PG_HI21	.text+0xc
    4:	90000000 	adrp	x0, 0 <.text>
			4: R_AARCH64_ADR_PREL_PG_HI21	.text+0x4
    8:	90000000 	adrp	x0, 0 <.text>
			8: R_AARCH64_ADR_PREL_PG_HI21	.text+0x4

So the ". - 8" expression has evaluated correctly, but the "." expression
has not.  Would you care to open a BZ for this ?

Cheers
   Nick