Re: [PATCH v1 0/3 CHIP: Support vendor script libraries

[Ulf Samuelsson <binutils@emagii.com>]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]


On 2023-03-16 09:23, Jan Beulich wrote:
> On 15.03.2023 21:03, Ulf Samuelsson via Binutils wrote:
>> On 2023-03-15 17:27, Michael Matz wrote:
>>> On Tue, 14 Mar 2023, Ulf Samuelsson via Binutils wrote:
>>>
>>>> Introduce the CHIP command for non-MRI script files.
>>>>
>>>> The motivation is that you want to simplify supporting microcontrollers.
>>>> You want include files that define the addresses for all peripherals
>>>> and the memory/bank organisation.
>>> Makes sense, but why is it not enough to use "INCLUDE(<chip>.inc)" in the
>>> linker script and passing -L$LD_VENDOR_DIR/<chip> on the linker command
>>> line?
>> Because it is a poor user interface.
> That's certainly a matter of taste.

As a generic user interface it is OK, but for the intended use, it adds 
a lot
of complexity which you do not need.

There are several parties involved in this.

 1. The semiconductor company  developing the chips, which often
    supplies a gcc toolchain.
 2. Independent S/W vendors supporting GNU toolchains.
 3. The team responsible for setting up the toolchain in a development
    organisation.
 4. The application team that uses the toolchain. They are likely to
    also use toolchains from other vendors.

Right now, semiconductor companies support their chips in their own way.

There is no common structure, so third party vendors are unlikely to get 
anything
from the semiconductor companies which can be used "as is".

The user will have the same difficulty in using the same toolchain for 
multiple vendors.

The GNU provider are likely to provide an installation script. This is 
run by the local
tools team and they will define locations, and the installation script
will output a script to setup the local build environment.

It is normally not neccessary for the application team to worry about 
where the chip specific files are.

Having to add plenty of "-L" directives or SEARCH_DIR commands just 
makes getting things to
run more difficult.

In some safety critical applications, you actually have to run through 
the build using two or more different
toolsuites, and then you want to minimize differences in the scripts.

The "CHIP <vendor>, <chip>" directive removes clutter in this process, and
encourages companies creating the tools to adopt a standard way of
supporting their chips, while not forcing them to do so.
>
>> You have to pass
>>
>> -L$PROJ_DIR/<chip>
>>
>> -L$LD_USER_DIR/<chip>
>>
>> -L$LD_VENDOR_DIR/<chip>
>>
>> to the linker every  time you link, and since most user would link with GCC
>> you would have to make it more complex since you
>> have to pass these things the linker through gcc.
> How does gcc make it any different? It's still all the same -L options,
> isn't it? You shouldn't need any -Wl,... afaict.

Yes, You are right

>> so your suggestion is a lot more verbose.
>>
>> I want to do
>>
>> arm-none-gcc  myapp.c
>>
>> and be done with it (assuming gcc will find the right linker script).
>>
>> Why program in C, when you can program in assembler?
> Interesting to see such a view nowadays; most projects strive to reduce
> the amount of assembly code they have to maintain, afaik.
It was a retoric question.

The "CHIP" command, like the C compiler makes things easier for the 
application programmer.


>
> Jan
Best Regards
Ulf Samuelsson