From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 8BE1D3858D1E for ; Mon, 13 Mar 2023 15:54:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8BE1D3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BA04321F82; Mon, 13 Mar 2023 15:54:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1678722883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GWnVOjIXMz55CFFs3fpNARxXd+QWj2BDDaukzzB93N0=; b=DgnGmB+KhFjNK5E8Wy/J7ESkhWr4jo/QtmG4nIEQhXXsLscDKd5cnXMjvR690K5HL9WpUJ irGwLE99DgpHLEagBPSvC38mLiFOkZuL+ojspstwmiG2VtDEOOrOS/eRf28hEeWIKGkoxX c1Drc6dbyL4LRWSkeRtIMCaZ/qKszSo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1678722883; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GWnVOjIXMz55CFFs3fpNARxXd+QWj2BDDaukzzB93N0=; b=PCuOpHAva2WWf8TPcuIyORSh3+wFbYq1TnMjKwhRthHccfTwMoHXIlH7Mom01MXWDP1ccX G5m+fAn+uelXOvAw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id AB9222C141; Mon, 13 Mar 2023 15:54:43 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 9FAB16316; Mon, 13 Mar 2023 15:54:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 9E6F162D0; Mon, 13 Mar 2023 15:54:43 +0000 (UTC) Date: Mon, 13 Mar 2023 15:54:43 +0000 (UTC) From: Michael Matz To: Ulf Samuelsson cc: binutils@sourceware.org, nickc@redhat.com Subject: Re: [PATCH v1 0/7 SECTOR: Support aligning to flash sector boundary In-Reply-To: <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com> Message-ID: References: <95D14810-3DEE-44ED-B071-72BC8C3C3AC0@emagii.com> <662cb2c6-e42d-4d46-3978-7159e86d88e5@emagii.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-1337231858-1678722883=:16810" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1337231858-1678722883=:16810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello, On Mon, 13 Mar 2023, Ulf Samuelsson wrote: > > So, a builtin function (however implemented) that actually gets you > > that very size for a given address makes the most sense IMHO. > > Not really. The proposal is to avoid having to figure out the boundaries > for each sector. and to avoid having to maintain files which aligns to > the sector. > > But I tried implementing > >   . = ALIGN(SECTOR); > > and that works now. > > If "." is within a sector, then it moves "." to beyond the sector, > otherwise it remains as it is. > > While > >   . = ALIGN(SECTOR(".")); > > allows you to get the sector for any address, what would be a reasonable > motivation for having this? That doesn't matter so much. The point is that the linker script already supports an assortment of expressions, one of them 'ALIGN(EXP,ALIGN)' (with EXP being optional and "dot" by default). This expression can be used in arbitrary places right now. If it makes sense to use it in arbitrary places? Probably not, but who knows the future? That's why syntax extensions to the ldscripts should not necessarily prescribe usage, and be orthogonal (that was my ultimate reason for suggesting to have something returning the sector-size for a given address). Basically: if we extend the syntax and can give reasonable and obvious meaning to the new constructs and nevertheless put in limits of usage right now, then this will eventually bite us in the future: a new usage turns up, the old syntax doesn't support it, but needs to be maintained for backward compatibility, and hence another new syntax needs to be invented that essentially does the same thing as the older syntax that turned out to be too limited. > To me, it just adds additional ways of introducing errors by increased > complexity in the syntax. Linkerscripts are a powerful tool, and many of the ways of how to use them incorrectly are because of too many ad-hoc additions at random syntax elements over the past decades. But using "FOOBAR(.)" outside an output section, so that "." isn't defined, and hence could be warned about, is _not_ a source of much rope to hang yourself. Ciao, Michael. ---1609957120-1337231858-1678722883=:16810--