On Tue, Oct 11, 2022 at 12:37 PM Nick Clifton <ni...@redhat.com> 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. > > A clever assembler might be able to rearrange the expression, assuming that > overflow is unimportant, but gas does not do that. 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 > > 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.
GCC has a global input_location conveniently available when all other bets are off. Maybe mention "relocation" in the error message somehow? So "expression is too complex to be resolved by a single relocation"? Richard. > > Cheers > Nick >
