From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emagii.se (www.emagii.com [185.133.207.17]) by sourceware.org (Postfix) with ESMTPS id 111713858C5F for ; Wed, 15 Mar 2023 20:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 111713858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=emagii.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emagii.com Received: from [10.175.196.145] (84-55-68-216.customers.ownit.se [84.55.68.216]) by emagii.se (Postfix) with ESMTPSA id B8B4E1201B1; Wed, 15 Mar 2023 21:03:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emagii.com; s=default; t=1678910604; bh=KhzVZqa++sFHDy46Tp42C7yvZ5uZOMZl8HZ9xEfQf3g=; h=Subject:To:From; b=f3G6XoWh5NHqcip8/YSPX13c33URsMwTR4FScENfb7AFaVPbawwmPR5vwekXvJvIP JogIFahHK33Nl3KW5x7uQT0N57TwfTSJjhCOO5lTD+2q0+vlpwXH7CqIFvktNlAw0J MluwhUZBRtWYzU7euLX70PuHrvhGUhMyY62l/Xws= Authentication-Results: emagii.beebytevps.io; spf=pass (sender IP is 84.55.68.216) smtp.mailfrom=binutils@emagii.com smtp.helo=[10.175.196.145] Received-SPF: pass (emagii.beebytevps.io: connection is authenticated) Message-ID: Date: Wed, 15 Mar 2023 21:03:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v1 0/3 CHIP: Support vendor script libraries Content-Language: en-US To: Michael Matz Cc: binutils@sourceware.org, nickc@redhat.com References: <20230314220114.1117782-1-binutils@emagii.com> From: Ulf Samuelsson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <167891060289.1930584.6030154310580718325@localhost.localdomain> X-PPP-Vhost: emagii.com X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_FAIL,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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(.inc)" in the > linker script and passing -L$LD_VENDOR_DIR/ on the linker command > line? Because it is a poor user interface. You have to pass -L$PROJ_DIR/ -L$LD_USER_DIR/ -L$LD_VENDOR_DIR/ 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///.    Plan to change 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