Re: Error: attempt to get value of unresolved symbol `L0'

["Pali Rohár" <pali@kernel.org>]

On Tuesday 11 October 2022 11:37:03 Nick Clifton wrote:
> Hi Pali, Hi Richard,
> 
> > Interesting... Another test case which is working fine:
> > 
> >    kernoffs:
> >    .word 0x40000 - (. - 0x0)
> 
> This works because this expression can be converted into an instruction
> and a relocation in the object file:
> 
>   % as t.s -o t.o
>   % objdump -dr t.o
>   Disassembly of section .text:
> 
>   00000000 <kernoffs>:
>    0:	0003fffc 	.word	0x0003fffc
> 			0: R_ARM_REL32	*ABS*
> 
> Which shows that when this object file is linked the word at offset 0
> inside the .text section should be converted into an absolute value of
> (pc - 0x4000), where pc is the address of the word.
> 
> This instruction however:
> 
> 	.word - (. - 0x80008000)
> 
> Cannot be converted since the linker would need to compute ((pc - 0x800800) * -1)
> which cannot be expressed by a single relocation.  Similarly:
> 
> 	.word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE)
> 
> Cannot be expressed by a single value, modified by a single relocation, even
> when the KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly
> time.

Hello! Thank you for this information. I would suggest to extend GAS
documentation to include this kind of information into . (dot) usage as
it is not really obvious that simple form with just addition and minus
operations results in something complex with multiplication. And also
that multiplication cannot be used in dot usage.

> A clever assembler might be able to rearrange the expression, assuming that
> overflow is unimportant, but gas does not do that.

This looks like some useful feature which is not supported...

> But just for reference the following would work:
> 
> 	.word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - .
> 
> 
> I agree however that this message:
> 
>         t.s: Error: attempt to get value of unresolved symbol `L0'
> 
> is unhelpful.  So I am going to check in a patch to change it to:
> 
> 	t.s: Error: expression is too complex to be resolved

Perfect, that would be better.

> I looked into providing a file name and line number with the error
> message, but this would involve reworking a lot of the assembler's
> internal expression parser.

Having file name and line number would be also useful as it took me
some time to figure out where is the issue...

> 
> Cheers
>   Nick
>