Re: Arm64: assembling adrp with operand involving .

[Jan Beulich <jbeulich@suse.com>]

On 09.05.2022 17:21, Nick Clifton wrote:
>> --- a/gas/config/tc-aarch64.c
>> +++ b/gas/config/tc-aarch64.c
>> @@ -604,7 +604,7 @@ aarch64_get_expression (expressionS *  e
>>     input_line_pointer = *str;
>>     in_aarch64_get_expression = true;
>>     if (defer_resolution)
>> -    seg = deferred_expression (ep);
>> +    seg = /*deferred_*/expression (ep);
>>     else
>>       seg = expression (ep);
>>     in_aarch64_get_expression = false;
>> @@ -8824,7 +8824,8 @@ md_apply_fix (fixS * fixP, valueT * valP
>>   
>>     /* Note whether this will delete the relocation.  */
>>   
>> -  if (fixP->fx_addsy == 0 && !fixP->fx_pcrel)
>> +  if (fixP->fx_addsy == 0 && !fixP->fx_pcrel
>> +      && aarch64_force_reloc (fixP->fx_r_type) <= 0)
>>       fixP->fx_done = 1;
>>   
>>     /* Process the relocations.  */
>>
>> But when using a transitive equate, the intermediate symbol is then
>> used, which still doesn't feel quite right. Hence my thought of
>> doing yet more evaluation of the expression.
> 
> I do not get what you are saying here.  Could you provide a small
> example of code that might experience this problem ?

	.text

	.set x, 0x12345678
	.eqv bar, x
foo:
	adrp	x0, x
	add	x0, x0, :lo12:x

	adrp	x0, bar
	add	x0, x0, :lo12:bar

With the proposed change, the first two relocations would be against
*ABS*:0x12345678, whereas the latter two relocations would be against
x. (Prior to the proposed change, the first two relocations are
against x and the latter two against bar.)

> Still, given that this approach appears to be simple, self-contained
> and correct, I am inclined to think that it is the best solution...
> 
> 
>> If, otoh, the symbol references in the relocs are indeed meant to be
>> as they are now,
> 
> As a general rule, this is one of those things that the target's assembler
> language specification ought to define.  Of course not all targets do have
> a well defined assembler language specification, so then we have to do the
> best that we can.

Hmm, I would have thought such rules ought to be largely arch-agnostic.

In this context, do you have any thoughts about "Arm64: follow-on to PR
gas/27217 fix"? I don't really feel comfortable committing this without
either you (as the author of the original fix) or one of the arch
maintainers having signaled agreement in some way. Of course, depending
on the further route taken for 28888 some (most) of what's done there
may disappear again (alongside parts of the original fix for 27217).

Jan

>> then the only other solution to the problem with .
>> that I can see is to introduce yet another expression parsing mode,
>> which would resolve . but defer everything else. One problem with
>> skipping evaluation of the expression is that in
>>
>> 	.text
>>
>> 	.set x, 0x12345678
>> 	.eqv bar, x
>> foo:
>> //	adrp	x0, x
>> //	add	x0, x0, :lo12:x
>> 	adrp	x0, bar
>> 	add	x0, x0, :lo12:bar
>>
>> 	.set x, 0x98765432
>> 	adrp	x0, x
>> 	add	x0, x0, :lo12:x
>> 	adrp	x0, bar
>> 	add	x0, x0, :lo12:bar
>>
>> the two pairs of relocations against "bar" necessarily can only
>> reflect one value, while "bar" being a forward ref would suggest
>> x'es original value to be used in the first pair, but x'es final
>> value to be used by the latter one.
> 
> Which would definitely confuse the programmer.  So I think that we
> should avoid this route unless specifically required by the target's
> assembler language specification.  (IE, for the AArch64, I could not
> find anything saying that this behaviour is required, so I think that
> we should not go down this route...)
> 
> Cheers
>    Nick
>