From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by sourceware.org (Postfix) with ESMTPS id 0AC893857806 for ; Tue, 11 Oct 2022 10:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0AC893857806 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EEEE861042; Tue, 11 Oct 2022 10:57:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A110C433D6; Tue, 11 Oct 2022 10:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665485837; bh=ESHJRrZQLhJNE8SpsADE9Nmw6HrGtnDVLo5EnqCdLGc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M4pP2T8iROec5N9KD4YcrY7rM5Xz2sPUpwOOD4fcASK1exCLZeBeZuEFEdFZLXpOZ cTtodzlK7vib1Shp38Nt8ySyuXGjzey7mndP+bIYK8hZ4yA0acD81MLyednUGMU4AI /CRHB9kVgjryNyqq8zqSa9seLFqFkEEeaPHVBecVwTX332ZDSDWLhk2GLktUEx7Sdl LiauPm50Y0JTbhbh4bXMgcoZl0eqvcnjTrGCfoXQb6wI2PsFCKRZsndiibdZC6k2rH Xq9Z+FnRtgBQFVun/fpjUkXmWEFuU3CWSKly2obmzP6ydcrqtWYvy50mS6UU6e5kzk U2b05yWgwsaMA== Received: by pali.im (Postfix) id 435CA7B3; Tue, 11 Oct 2022 12:57:14 +0200 (CEST) Date: Tue, 11 Oct 2022 12:57:14 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Nick Clifton Cc: Richard Biener , gcc@gcc.gnu.org, binutils@sourceware.org Subject: Re: Error: attempt to get value of unresolved symbol `L0' Message-ID: <20221011105714.r5x7x4x5xsi7o7pz@pali> References: <20221010171809.oqecrrdguv5hcta2@pali> <20221011074309.ojqoxwsosm6v7ozc@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 : > 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 >