Re: Arm64: assembling adrp with operand involving .

[Jan Beulich <jbeulich@suse.com>]

On 14.02.2022 14:35, Nick Clifton wrote:
>> 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.

I've mentioned this aspect in the bug (see below), but now that I look
again I'm not sure anymore: Wouldn't this be .text+0? And isn't it
getting close only because no further insns are following?

>  Would you care to open a BZ for this ?

Bug 28888.

Jan