Question: default linker scripts and emulations

Question: default linker scripts and emulations

[Georg-Johann Lay]

GCC could generate better code for some devices if it could use an
adjusted linker description file for these devices.

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.

In the case a new emulation is required:

The compiler has currently around 60 multilib variants, and a new emulation
would add yet another 6 multilibs. Therefore, it would be desirable to
re-use the old multilib (which still has some devices in it).

Say the old machine is avr:102 and the new one is avr:108, but the generated
code is all the same, only difference is ld script. The compiler would
map avr:108 to avr:102 multilibs.

What's the best way to implement this in Binutils?

Is it enough to tell that the two machines / emulations are compatible
in bfd_arch_info_type.compatible() ?  Or maybe a smarter approach?

Thanks in advance

Johann

Re: Question: default linker scripts and emulations

[Nick Clifton]

Hi Johann,

> GCC could generate better code for some devices if it could use an
> adjusted linker description file for these devices.
> 
> 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.
 >
> In the case a new emulation is required:
> 
> The compiler has currently around 60 multilib variants, and a new emulation
> would add yet another 6 multilibs. Therefore, it would be desirable to
> re-use the old multilib (which still has some devices in it).
> 
> Say the old machine is avr:102 and the new one is avr:108, but the generated
> code is all the same, only difference is ld script. The compiler would
> map avr:108 to avr:102 multilibs.
> 
> What's the best way to implement this in Binutils?

Actually it might be easier to implement this using gcc's spec file syntax
rather than adding a new linker option.  For example

   gcc [...other gcc options...] --specs=avr108.spec

and avr108.spec could contain:

   *self_spec:
   + %{!T{-T avr108.ld}}

The spec file syntax allows for options to be conditionally added, so in this
case a "-T avr108.ld" would be added to the linker command line only if the
user has not already provided a -T option of their own.

[This is totally not tested by me, but I think that in theory it should work].

Cheers
   Nick

Re: Question: default linker scripts and emulations

[Georg-Johann Lay]

Ni Nick

Am 06.12.23 um 12:21 schrieb Nick Clifton:
> Hi Johann,
> 
>> GCC could generate better code for some devices if it could use an
>> adjusted linker description file for these devices.
>>
>> 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.
>  >
>> In the case a new emulation is required:
>>
>> The compiler has currently around 60 multilib variants, and a new 
>> emulation
>> would add yet another 6 multilibs. Therefore, it would be desirable to
>> re-use the old multilib (which still has some devices in it).
>>
>> Say the old machine is avr:102 and the new one is avr:108, but the 
>> generated
>> code is all the same, only difference is ld script. The compiler would
>> map avr:108 to avr:102 multilibs.
>>
>> What's the best way to implement this in Binutils?
> 
> Actually it might be easier to implement this using gcc's spec file syntax
> rather than adding a new linker option.  For example
> 
>    gcc [...other gcc options...] --specs=avr108.spec
> 
> and avr108.spec could contain:
> 
>    *self_spec:
>    + %{!T{-T avr108.ld}}
> 
> The spec file syntax allows for options to be conditionally added, so in 
> this
> case a "-T avr108.ld" would be added to the linker command line only if the
> user has not already provided a -T option of their own.
> 
> [This is totally not tested by me, but I think that in theory it should 
> work].
> 
> Cheers
>    Nick

I don't see how this can work, because there is no way to inspect the
contents of the provided file:

* When the user provides a complete ld-script, then use his script instead
of avr108.ld.

* When the user provides an ld-script snipped with INSERT AFTER etc, then use
avr108.ld but with the augmentation provided by the user.

But the compiler (or specs handling) cannot tell which is which.

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.

Cheers,

Johann

Re: Question: default linker scripts and emulations

[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.

Re: Question: default linker scripts and emulations

[Georg-Johann Lay]

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

Re: Question: default linker scripts and emulations

[Nick Clifton]

Hi Johann,

> 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).

Ok, that seems a lot more reasonable.

So - what emulations do you want, and how do they differ from the already
existing (avr) emulations ?

If you want to write a patch for the binutils that would be fine, otherwise
if you can outline what you need I will do my best to create the patch for
you.

Cheers
   Nick

Re: Question: default linker scripts and emulations

[Georg-Johann Lay]

Am 08.12.23 um 12:29 schrieb Nick Clifton:
> Hi Johann,
> 
>> 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).
> 
> Ok, that seems a lot more reasonable.
> 
> So - what emulations do you want, and how do they differ from the already
> existing (avr) emulations ?
> 
> If you want to write a patch for the binutils that would be fine, otherwise
> if you can outline what you need I will do my best to create the patch for
> you.
> 
> Cheers
>    Nick

Hi Nick,

I already have a working patch.  The bulk of the changes is in avr.sc
because a new MEMORY region is needed etc.  See PR31124 where I lined
out some of the intended features.

If it ever comes to a review, I guess you would be the one to approve a 
patch ? (All in ld/ and all for target avr)

Cheers,

Johann