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(.inc)" in the >>> linker script and passing -L$LD_VENDOR_DIR/ 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/ >> >> -L$LD_USER_DIR/ >> >> -L$LD_VENDOR_DIR/ > 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.