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

[Michael Matz]

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.