Re: Question: default linker scripts and emulations

[Georg-Johann Lay <avr@gjlay.de>]

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