From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.24]) by sourceware.org (Postfix) with ESMTPS id 0261F3858D20 for ; Thu, 7 Dec 2023 18:29:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0261F3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gjlay.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=gjlay.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0261F3858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=85.215.255.24 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701973796; cv=pass; b=R1tNoY1iUX0uCDa4GCfSE6NRBkCWHOK7m4IvJ1D6C5U8tX4qzHkYh0jOFb6Ql80bZfJYQJm5jn7t6IGqhikeCx3PDt03Dp/tqq5Op2sy1Rjj8iJOO37JfKDRIB+YcgZz0w1cTHWfzGBhtfa416MnPki4wbeiDj3kNi7AYNZQ07o= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701973796; c=relaxed/simple; bh=nd0aqZQgdcyJKzwwr/kFwim7LsXIE4P6Xna8SoXrjsI=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=QHwz0phQRolsZ4USZ7qZ81ENIXYufHHYnBGO0XABPBwr0qWkpYBJSUcvnZ5g81kIBX72efqJsFTDSzKoUyBJ6RCA+WD1btoXAKVo3mKyuDdH2dBNmNsS14dYMfXAHbSMxItiuZQZQotBJbdkP7RlU9U2zw8VxmQmdsgqWt9Ivyw= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; t=1701973792; cv=none; d=strato.com; s=strato-dkim-0002; b=s8Gngjr+x0F78izTtQ+P6eFRa5zrN22lLbQkSwVJRxwC3bh45pf5RucABqwm3qfRJ7 /eu4+vx8jJDtW+MWlCC6TCqHvQez4rAZs8/YtikzshJJ2dyssV+pxmEbf0vTp0QlQPnf HYo71YrwQyZd8rY9ruDc1KYkLcJ8hEkxbhSIVQjZNXaVlf/QRXntWS/hPvKJC5k+AGjm pGbn9MvB4jNMo8sjL49z/w5jVAYyEBmr+fl0l4TyVD1ZVJU/KE7x1Lme0Y6FSIBfWLU9 yPAKHrIkL5WE2QHU+XR0sudvDrnWm1hGP8KitqGXJsvY3Ql2PmK8zWPTDDnKPjXR7bXN /uEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1701973792; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=W6hVE/J9W4gIVFxoEY5Cz9U16YzncYUEftXfTsCNIvU=; b=CDKM81tNr+bhMG/hGOnmvlMcWEwdxIkIacrqXmxlXJKky+KumXqiRSHfLinWV/e34E +UtkFbdfvxVk8iAhnwNyScX7ZOdYLv6iu+Z4mJ5S6GWQV6ai10qZQfaDRorPezaRPyI/ gouwXCb+XpnFuGZFhsRop6/+ORpAaVpfbIubbFAZajg3CGTnCB3cTPMCQI99F3LWqsAc jqQj1F6koCf1ZdB7gI/V65na1HyBgiW89Hk5XHwf2EdtQ1OHqfpSNQmww5fNOKB/4EkL nNCDSzsoyEO+FbEpIaPXCUPocD4fgLHpqUHwVtoV1/sh1PDotPzDWiV4HdVfawgAEIfn Ae7A== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1701973791; s=strato-dkim-0002; d=gjlay.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=W6hVE/J9W4gIVFxoEY5Cz9U16YzncYUEftXfTsCNIvU=; b=lv4b8OnLFIz8B03/aW5bdYNyKRPpO+JCrX1n7uU3bcsTaytfXk71VBIYnS8Uw7oA5F SgYwoGv41tLE+uHSNaFACxVRtT5AvZMJSQc8ntYNmuwdeoacRgah+qu+C95kVI+Y22VD pb/kJmL1kxZ1BiY1xMl1ipX9ylje4aHFf3soHGiv3UVQCpqjfAZsjWx6hj4i18UpF898 htBWYn69H1sv7KRbqIRtXYOQeiJlIzF/mCu+Boo+a5PL8N67Zzp8mB61RZv/OvuCewpI uC1HMEVp62OmIllEyGePT6gtY/umHBugvz1LbvAdhK1gBk/FCMkPVDtpD6Zas8PHHpup yPcw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1701973791; s=strato-dkim-0003; d=gjlay.de; h=In-Reply-To:From:References:To:Subject:Date:Message-ID:Cc:Date:From: Subject:Sender; bh=W6hVE/J9W4gIVFxoEY5Cz9U16YzncYUEftXfTsCNIvU=; b=TIRKVqUSHwQ2GtObKnL4Hf7s0D4nh6PPoGLqNJ5VHoLvvxc4HWejEsFY0m1uZpHBd7 4uIQr89MH+tg8LJk01DQ== X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkSjsSjo3O/MHXSz1aalw==" Received: from [192.168.2.102] by smtp.strato.de (RZmta 49.10.0 DYNA|AUTH) with ESMTPSA id Lf3d8bzB7ITpIcr (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 7 Dec 2023 19:29:51 +0100 (CET) Message-ID: <22a26c57-7fab-4372-866a-4aa2b7c5a523@gjlay.de> Date: Thu, 7 Dec 2023 19:29:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question: default linker scripts and emulations Content-Language: en-US To: Nick Clifton , binutils@sourceware.org References: <26f6143b-cd4c-4c7d-bf06-4265d17f417f@gjlay.de> <627688a1-176c-4a8e-984e-3848c902b273@redhat.com> <93a44089-7ad5-4122-9df4-1cce6042c648@redhat.com> From: Georg-Johann Lay In-Reply-To: <93a44089-7ad5-4122-9df4-1cce6042c648@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Am 07.12.23 um 16:50 schrieb Nick Clifton: > Hi Georg-Johann, > >>>> Is it possible to add a new option to the linker so it picks a >>>> different ld script, such that: >>>> >>>> o The same emulation is used. >>>> >>>> o All works a usual, e.g. when the user request -T myscript.ld, use >>>> myscript.ld provided it is a complete ld script and not just INSERT >>>> AFTER etc. > > >> Then there's the technical problem that the compiler needs to know the >> install path (in configure and when running) and provide the complete >> path to avr108.ld. >> >> Just dropping avr108.ld in $install/avr/lib/ldscripts is not enough >> that the linker can find it with -Tavr108.ld >> >> Then the specs would need to be able to select different ld-script >> flavours like *.x, *.xn, *.xr, etc depending on options like -r and >> whatnot. >> >> And the default ld-scripts are contained in the ld executable, so that >> changing the scripts on file won't have any effect (except you select >> them explicitly with -T). >> >> IMO specs cannot resolve that in a reasonable way, in  particular the >> distinction between complete ld-scripts and snippets. > > OK, so it sounds to me like what is needed is an option to tell the linker > where to find its default scripts, and if used, override the use of the > built in scripts.  So for example: > >   avr-ld foo.o >      [Uses built in avr1.x script] > >   avr-ld -m avr2 foo.o >      [Uses built in avr2.x script] > >   avr-ld -m avr2 -r foo.o >      [Uses built in avr2.xr script] > >   avr-ld -m avr2 -T bar.ld foo.o >      [Uses ./bar.ld unless it contains INSERT, in which case it uses > the built >       in avr2.x script augmented by ./bar.ld] > >   avr-ld --default-script-path /usr/lib/avr foo.o >       [Uses /usr/lib/avr/avr1.x.  Generates an error if it does not exist. >        Does not use the built in avr1.x script] > >   avr-ld -m avr2 --default-script-path /usr/lib/avr foo.o >       [Uses /usr/lib/avr/avr2.x.  Generates an error if it does not exist. >        Does not use the built in avr2.x script] > >   avr-ld -m avr2 -r --default-script-path /usr/lib/avr foo.o >       [Uses /usr/lib/avr/avr2.xr.  Generates an error if it does not > exist. >        Does not use the built in avr2.xr script] > >   avr-ld -m avr2 -T bar.ld --default-script-path /usr/lib/avr foo.o >      [Uses ./bar.ld unless it contains INSERT, in which case it uses >       /usr/lib/avr/avr2.x augmented by ./bar.ld] > > And, for completeness sake, assuming that bar.ld does not exist in the > current directory: > >  avr-ld -m avr2 -L /usr/foo -T bar.ld --default-script-path > /usr/lib/avr foo.o >      [Uses /usr/foo/bar.ld unless it contains INSERT, in which case it > uses >       /usr/lib/avr/avr2.x augmented by /usr/foo/bar.ld] > > Is this what you had in mind ? > > Cheers >   Nick > > PS, If this is what you had in mind, then I think that it could be done, >   but I am not sure that it should be done.  I feel that their ought to >   be an easier way to achieve the same results without adding any new >   code to the linker.  I am not sure - at the moment - what that easier >   way might be however. Hi Nick, I already played around with -dT / --default-script but was not really convinced that it's easy to get correct and easy to grasp (device-specs is user-land after all). My current solution only requires a few changes to Binutils: * Introduce new emulations. * In ld/emulparams/avr*.sh, just set ARCH=avr:102 (something that already exists) etc. and everything falls into place. Benefit is that ld-scripts are maintained in one canonical place. Anything other than a new emulation seems not feasible because ld/genscripts.sh has so many implicit assumptions that it's no fun to fight against it... Just swim with the flow et voilà; it's just a few lines in ld/Makefile.am and ld/configure.tgt (apart from the ld-scripts generation, which is just where I want that to happen). Now I can narrow down gcc and libc bits. Thank you so much! Cheers, Johann