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

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

[binutils]

Patchset 1

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.

CHIP "<chip>" will add directories to the include directory list
and will then include the "<chip>.inc" file.

chip "<chip>" will add 
* "$PROJ_DIR"
* "$LD_USER_DIR/<chip>"
* "$LD_VENDOR_DIR/<chip>"
to the search list for script files.

The search order will be:

"<Current directory>"
"$PROJ_DIR"
"$LD_USER_DIR/<chip>"
"$LD_VENDOR_DIR/<chip>"

This allows the vendor to supply a directory tree (LD_VENDOR_DIR).
with a subdirectory for each chip.

The subdirectory contains the "<chip>.inc" file which
can have the flash sectors using the BANK command
(patch posted to the link) as well as symbols
for all the peripherals for the chip.

Obviously, the vendor can place other files there as well.

chip "at91sam7s64"

would result in the linker including the file
$LD_VENDOR_DIR/at91sam7s64/at91sam7s64.inc

Since the vendor might be late with supplying include files
for a chip, the user can create a similar directory in LD_USER_DIR.

chip "at91sam7s64"

This would result in the linker including the file
$LD_USER_DIR/atmel/at91sam7s64/at91sam7s64.inc
since LD_USER_DIR is before LD_VENDOR_DIR in the search order.

If the user wants to simply put the file in their project
they can rely on the search order, or put the file in $PROJ_DIR

chip "at91sam7s64";

This would result in the linker including the file
$PROJ_DIR/at91sam7s64.inc

=================================

I am considering a further extension:

chip "at91sam7s64", "atmel";

This would result in the linker including the file
$LD_VENDOR_DIR/atmel/at91sam7s64/at91sam7s64.inc

[PATCH v1 1/3] CHIP: ldlex.l
[PATCH v1 2/3] CHIP: ldgram.y
[PATCH v1 3/3] CHIP: language additions

[PATCH v1 1/3] CHIP: ldlex.l

[binutils]

From: Ulf Samuelsson <ulf@emagii.com>

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
---
 ld/ldlex.l | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ld/ldlex.l b/ld/ldlex.l
index 32336cf0be2..bd03af2383a 100644
--- a/ld/ldlex.l
+++ b/ld/ldlex.l
@@ -353,7 +353,7 @@ V_IDENTIFIER [*?.$_a-zA-Z\[\]\-\!\^\\]([*?.$_a-zA-Z0-9\[\]\-\!\^\\]|::)*
 <MRI>"ABSOLUTE"			{ RTOKEN(ABSOLUTE); }
 <MRI>"ALIGNMOD"			{ RTOKEN(ALIGNMOD);}
 <MRI>"ALIGN"			{ RTOKEN(ALIGN_K);}
-<MRI>"CHIP"			{ RTOKEN(CHIP); }
+<SCRIPT,MRI>"CHIP"		{ RTOKEN(CHIP); }
 <MRI>"BASE"			{ RTOKEN(BASE); }
 <MRI>"ALIAS"			{ RTOKEN(ALIAS); }
 <MRI>"TRUNCATE"			{ RTOKEN(TRUNCATE); }
@@ -370,7 +370,7 @@ V_IDENTIFIER [*?.$_a-zA-Z\[\]\-\!\^\\]([*?.$_a-zA-Z0-9\[\]\-\!\^\\]|::)*
 <MRI>"absolute"			{ RTOKEN(ABSOLUTE); }
 <MRI>"alignmod"			{ RTOKEN(ALIGNMOD);}
 <MRI>"align"			{ RTOKEN(ALIGN_K);}
-<MRI>"chip"			{ RTOKEN(CHIP); }
+<SCRIPT,MRI>"chip"		{ RTOKEN(CHIP); }
 <MRI>"base"			{ RTOKEN(BASE); }
 <MRI>"alias"			{ RTOKEN(ALIAS); }
 <MRI>"truncate"			{ RTOKEN(TRUNCATE); }
-- 
2.34.1

[PATCH v1 2/3] CHIP: ldgram.y

[binutils]

From: Ulf Samuelsson <ulf@emagii.com>

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
---
 ld/ldgram.y | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ld/ldgram.y b/ld/ldgram.y
index 8240cf97327..e64d43880d1 100644
--- a/ld/ldgram.y
+++ b/ld/ldgram.y
@@ -343,6 +343,9 @@ ifile_p1:
 	|	INCLUDE filename
 		{ ldfile_open_command_file ($2); }
 		ifile_list END
+	|	CHIP filename
+		{ ldfile_open_chip_file ($2); }
+		ifile_list END
 	|	NOCROSSREFS '(' nocrossref_list ')'
 		{
 		  lang_add_nocrossref ($3);
-- 
2.34.1

[PATCH v1 3/3] CHIP: language additions

[binutils]

From: Ulf Samuelsson <ulf@emagii.com>

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
---
 ld/ldfile.c | 29 ++++++++++++++++++++++++++++-
 ld/ldfile.h |  2 ++
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/ld/ldfile.c b/ld/ldfile.c
index b8fd4e5d8e0..9e9099dafae 100644
--- a/ld/ldfile.c
+++ b/ld/ldfile.c
@@ -710,7 +710,6 @@ ldfile_open_command_file_1 (const char *name, enum script_open_style open_how)
       einfo (_("%F%P: cannot open linker script file %s: %E\n"), name);
       return;
     }
-
   track_dependency_files (name);
 
   lex_push_file (ldlex_input_stack, name, sysrooted);
@@ -729,6 +728,34 @@ ldfile_open_command_file (const char *name)
   ldfile_open_command_file_1 (name, script_nonT);
 }
 
+void
+ldfile_open_chip_file (const char *name)
+{
+  char *fullname;
+  char *proj   = getenv("PROJ_DIR");
+  if (proj != NULL)
+    {
+      ldfile_add_library_path(proj, false);
+    }
+  char *user   = getenv("LD_USER_DIR");
+  if (user != NULL)
+    {
+      fullname = concat(user, slash, name , (const char *) NULL);
+      ldfile_add_library_path(fullname, false);
+      free(fullname);
+    }
+  char *vendor = getenv("LD_VENDOR_DIR");
+  if (vendor != NULL)
+    {
+      fullname = concat(vendor, slash, name , (const char *) NULL);
+      ldfile_add_library_path(fullname, false);
+      free(fullname);
+    }
+  fullname = concat(name, ".inc", (const char *) NULL);
+  ldfile_open_command_file_1 (fullname, script_nonT);
+  free(fullname);
+}
+
 void
 ldfile_open_script_file (const char *name)
 {
diff --git a/ld/ldfile.h b/ld/ldfile.h
index defb550f76b..3b43e549928 100644
--- a/ld/ldfile.h
+++ b/ld/ldfile.h
@@ -46,6 +46,8 @@ extern void ldfile_add_library_path
   (const char *, bool cmdline);
 extern void ldfile_open_command_file
   (const char *name);
+extern void ldfile_open_chip_file
+  (const char *name);
 extern void ldfile_open_script_file
   (const char *name);
 extern void ldfile_open_default_command_file
-- 
2.34.1

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

[Ulf Samuelsson]

There are no NEWS, ld.texi or testsuite for these patches yet
since they are just RFCs at the moment.

Need to get the copyright issue sorted out.

I finally got reply from FSF on Copyrights, but they think it could take
some time to process.

Best Regards
Ulf Samuelsson

On 2023-03-14 23:01, Ulf Samuelsson via Binutils wrote:
> Patchset 1
>
> 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.
>
> CHIP "<chip>" will add directories to the include directory list
> and will then include the "<chip>.inc" file.
>
> chip "<chip>" will add
> * "$PROJ_DIR"
> * "$LD_USER_DIR/<chip>"
> * "$LD_VENDOR_DIR/<chip>"
> to the search list for script files.
>
> The search order will be:
>
> "<Current directory>"
> "$PROJ_DIR"
> "$LD_USER_DIR/<chip>"
> "$LD_VENDOR_DIR/<chip>"
>
> This allows the vendor to supply a directory tree (LD_VENDOR_DIR).
> with a subdirectory for each chip.
>
> The subdirectory contains the "<chip>.inc" file which
> can have the flash sectors using the BANK command
> (patch posted to the link) as well as symbols
> for all the peripherals for the chip.
>
> Obviously, the vendor can place other files there as well.
>
> chip "at91sam7s64"
>
> would result in the linker including the file
> $LD_VENDOR_DIR/at91sam7s64/at91sam7s64.inc
>
> Since the vendor might be late with supplying include files
> for a chip, the user can create a similar directory in LD_USER_DIR.
>
> chip "at91sam7s64"
>
> This would result in the linker including the file
> $LD_USER_DIR/atmel/at91sam7s64/at91sam7s64.inc
> since LD_USER_DIR is before LD_VENDOR_DIR in the search order.
>
> If the user wants to simply put the file in their project
> they can rely on the search order, or put the file in $PROJ_DIR
>
> chip "at91sam7s64";
>
> This would result in the linker including the file
> $PROJ_DIR/at91sam7s64.inc
>
> =================================
>
> I am considering a further extension:
>
> chip "at91sam7s64", "atmel";
>
> This would result in the linker including the file
> $LD_VENDOR_DIR/atmel/at91sam7s64/at91sam7s64.inc
>
> [PATCH v1 1/3] CHIP: ldlex.l
> [PATCH v1 2/3] CHIP: ldgram.y
> [PATCH v1 3/3] CHIP: language additions
>

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

[Michael Matz]

Hello,

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?

The harcoding of environment variables seems very specific, especially 
for the unsuffixed PROJ_DIR (which definitely looks more like something 
for the build system to add).  So, if you really want to avoid cmdline 
additions, maybe introducing a way to specify envvar names for the 
SEARCH_DIR directive would be better?

Like

  SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
  INCLUDE(at91sam7s64.inc)

Support for envvars in SEARCH_DIR (and possibly INCLUDE as well) would 
seem somewhat useful in its own right I think.  (Yes, it would conflict 
with potential current use of '$' as a starter for a filename 
component, in which case quoting can be used to disambiguate).


Ciao,
Michael.

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

[Ulf Samuelsson]

On 2023-03-15 17:27, Michael Matz wrote:
> Hello,
>
> 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.

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.

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?

> The hardcoding of environment variables seems very specific, especially
> for the unsuffixed PROJ_DIR (which definitely looks more like something
> for the build system to add).  So, if you really want to avoid cmdline
> additions, maybe introducing a way to specify envvar names for the
> SEARCH_DIR directive would be better?

Right now, the LD_USER_DIR and LD_VENDOR_DIR are the important ones

I think in the end, it might be better to specify the PROJ_DIR during 
./configure
but that can come later.

The other two should be fixed *as is* to avoid a mess.
People that want to use the feature should adopt their build. It is not 
difficult.

You do not want TI to have LD_TI_DIR and NXP using LD_NXP_DIR for the 
same thing.

>
> Like
>
>    SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
>    INCLUDE(at91sam7s64.inc)

It is:

   SEARCH_DIR($PROJ_DIR/at91sam7s64)
   SEARCH_DIR($LD_USER_DIR/at91sam7s64)
   SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
   INCLUDE(at91sam7s64.inc)

    CHIP "at91sam7s64" is much better.

    I plan to change it to add the vendor

    CHIP atmel, at91sam7s64

    This means that different companies can settle on LD_VENDOR_DIR
    and install in LD_VENDOR_DIR/<vendor>/<chip>/<chip>.<ext>

    Plan to change <ext> from ".inc" to ".chp"

    The CHIP command also allow things to change, if needed.

>
> Support for envvars in SEARCH_DIR (and possibly INCLUDE as well) would
> seem somewhat useful in its own right I think.  (Yes, it would conflict
> with potential current use of '$' as a starter for a filename
> component, in which case quoting can be used to disambiguate).
>
>
> Ciao,
> Michael.

Best Regards
Ulf Samuelsson

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

[Jan Beulich]

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.

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

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

Jan

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

[Ulf Samuelsson]

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

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

[Michael Matz]

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

Hello,

On Wed, 15 Mar 2023, Ulf Samuelsson 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.

But it's the standard interface to specify search paths.

> You have to pass
> 
> -L$PROJ_DIR/<chip>
> 
> -L$LD_USER_DIR/<chip>
> 
> -L$LD_VENDOR_DIR/<chip>

Yes, and if the user can't be bothered to write this into their Makefiles, 
then I don't know what to say.

> I want to do
> 
> arm-none-gcc  myapp.c
> 
> and be done with it (assuming gcc will find the right linker script).

And how do you propose that the right linker script is found (if not via 
-L specifications of search paths or some default config in the 
arm-none-gcc that then could as well include the search dirs you want to 
add)?  And why do you think that multiple SEARCH_DIR directives in that 
very linker script (assuming they would then understand envvars) are so 
cumbersome that it's better to complicate the code of ld, instead of a 
couple more lines in the linker script?

> The other two should be fixed *as is* to avoid a mess.
> People that want to use the feature should adopt their build. It is not
> difficult.

Exactly, they should adopt their build, it's not difficult to add linker 
search paths.  As soon as the developers become serious in their 
development they will have a build environment, Makefile or whatever else.  
That's the place were they would add the search paths and be done with 
it.

> You do not want TI to have LD_TI_DIR and NXP using LD_NXP_DIR for the same
> thing.

True, though I wouldn't even see much issues with that, to be honest.  As 
long as the docu of the chip vendor and the template configs for their 
toolchain correctly sets up the above it would all be hidden away in 
linker scripts or template makefiles anyway, so the specific names of the 
environment variables actually doesn't matter much.  That's another reason 
why I'm triggered by the submission.  Why should we hardcode these 
specific names in the linker binary?

> > Like
> > 
> >    SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
> >    INCLUDE(at91sam7s64.inc)
> 
> It is:
> 
>   SEARCH_DIR($PROJ_DIR/at91sam7s64)
>   SEARCH_DIR($LD_USER_DIR/at91sam7s64)
>   SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
>   INCLUDE(at91sam7s64.inc)

Or

  SEARCH_DIR($PROJ_DIR)
  SEARCH_DIR($LD_USER_DIR)
  SEARCH_DIR($LD_VENDOR_DIR)

(in the base linker script that comes with the chip toolchain) and

  INCLUDE(at91sam7s64/at91sam7s64.inc)

(in the applications linker script) (or "at91sam7s64/chip.inc", or with 
your additional idea "atmel/at91sam7s64/chip.inc").

And this all assumes a very specific layout of the whole thing.  That's 
the problem with the proposal: it encodes a specific way of working that 
happens to work for you (or that you think will work for you and everyone 
else).  The tools we provide should enable all kinds of workflows and I'm 
trying to think of ways to extend the functionality in such way that it 
enables your workflow without setting it in stone.


Ciao,
Michael.

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

[Ulf Samuelsson]

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


On 2023-03-16 16:05, Michael Matz wrote:
> Hello,
>
> On Wed, 15 Mar 2023, Ulf Samuelsson 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.
> But it's the standard interface to specify search paths.

The linker already has predefined search paths.

>
>> You have to pass
>>
>> -L$PROJ_DIR/<chip>
>>
>> -L$LD_USER_DIR/<chip>
>>
>> -L$LD_VENDOR_DIR/<chip>
> Yes, and if the user can't be bothered to write this into their Makefiles,
> then I don't know what to say.


>> I want to do
>>
>> arm-none-gcc  myapp.c
>>
>> and be done with it (assuming gcc will find the right linker script).
> And how do you propose that the right linker script is found (if not via
> -L specifications of search paths or some default config in the
> arm-none-gcc that then could as well include the search dirs you want to
> add)?  And why do you think that multiple SEARCH_DIR directives in that
> very linker script (assuming they would then understand envvars) are so
> cumbersome that it's better to complicate the code of ld, instead of a
> couple more lines in the linker script?

The "-L" directive will remain together with the SEARCH_DIR command.

The linker file will be found in exactly the same way as it has been 
found before.

include files will be found in exactly the same way as it has been found 
before.

You have 70 lines of code in the linker that replaces 4-5 lines of code in
*each* project worldwide that uses this feature.

Since none of the code changes any linker code (except the grammar)

the effect of the ld code is trivial.

If the "CHIP" directive is not used, there is no effect on the linker.

To me, that is an easy tradeoff.

The problem with SEARCH directives, is code is less portable.
It leads inevitably to companies using a variety of environment variables
for exactly no benefit.

If people want to use the SEARCH directive, they still can.


>
>> The other two should be fixed *as is* to avoid a mess.
>> People that want to use the feature should adopt their build. It is not
>> difficult.
> Exactly, they should adopt their build, it's not difficult to add linker
> search paths.  As soon as the developers become serious in their
> development they will have a build environment, Makefile or whatever else.
> That's the place were they would add the search paths and be done with
> it.

No, but it is having a bad effect on a global level.
These include files should normally come from another party.
Not having a standard for this handles is putting sand in the machinery.

>> You do not want TI to have LD_TI_DIR and NXP using LD_NXP_DIR for the same
>> thing.
> True, though I wouldn't even see much issues with that, to be honest.  As
> long as the docu of the chip vendor and the template configs for their
> toolchain correctly sets up the above it would all be hidden away in
> linker scripts or template makefiles anyway, so the specific names of the
> environment variables actually doesn't matter much.  That's another reason
> why I'm triggered by the submission.  Why should we hardcode these
> specific names in the linker binary?

Because not having a standard increases the development effort to switch 
vendor.


>>> Like
>>>
>>>     SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
>>>     INCLUDE(at91sam7s64.inc)
>> It is:
>>
>>    SEARCH_DIR($PROJ_DIR/at91sam7s64)
>>    SEARCH_DIR($LD_USER_DIR/at91sam7s64)
>>    SEARCH_DIR($LD_VENDOR_DIR/at91sam7s64)
>>    INCLUDE(at91sam7s64.inc)
> Or
>
>    SEARCH_DIR($PROJ_DIR)
>    SEARCH_DIR($LD_USER_DIR)
>    SEARCH_DIR($LD_VENDOR_DIR)
>
> (in the base linker script that comes with the chip toolchain) and
>
>    INCLUDE(at91sam7s64/at91sam7s64.inc)
>
> (in the applications linker script) (or "at91sam7s64/chip.inc", or with
> your additional idea "atmel/at91sam7s64/chip.inc").

You want to have a separation between the toolchain and the include files.

Otherwise, you need to install a new toolchain, just because you have
added a component to the the toolchain.

Also, you want to collect the chip definitions from multiple vendors to 
a single directory tree.

An example of difficulties would be that one vendor with 10 parts has a 
single directory
for all the script files, while another vendor with 3000 parts has a 
directory structure
like I proposed. If you have 50 processor vendors, each with their own 
structure
you add a large burden on the tool supplier.

>
> And this all assumes a very specific layout of the whole thing.  That's
> the problem with the proposal: it encodes a specific way of working that
> happens to work for you (or that you think will work for you and everyone
> else).  The tools we provide should enable all kinds of workflows and I'm
> trying to think of ways to extend the functionality in such way that it
> enables your workflow without setting it in stone.

The tools enables all kinds of toolflows, and will still enable all kind 
of toolflows.

It gives an option to make the toolflow smoother to the user with the 
"CHIP" command.

Any "extension" to the idea should consider the effect on the user.

The key questions:

  * How much work will it be to switch from one processor to another in
    the same family?
  * How much work will it be to switch from one processor vendor to another?
  * How easy is it to support a new processor - before vendor support is
    available?
  * How easy is it to create a toolchain with support for multiple
    semiconductor vendors.

The proposal is focusing on these things.

Best Regards
Ulf Samuelsson

>
>
> Ciao,
> Michael.