From: Michael Matz <matz@suse.de>
To: Ulf Samuelsson <binutils@emagii.com>
Cc: binutils@sourceware.org, nickc@redhat.com
Subject: Re: [PATCH v1 0/3 CHIP: Support vendor script libraries
Date: Thu, 16 Mar 2023 15:05:37 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2303161417370.16810@wotan.suse.de> (raw)
In-Reply-To: <c0d1bb49-3d79-f503-605a-ff144686480f@emagii.com>
[-- 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.
next prev parent reply other threads:[~2023-03-16 15:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 22:01 binutils
2023-03-14 22:01 ` [PATCH v1 1/3] CHIP: ldlex.l binutils
2023-03-14 22:01 ` [PATCH v1 2/3] CHIP: ldgram.y binutils
2023-03-14 22:01 ` [PATCH v1 3/3] CHIP: language additions binutils
2023-03-14 22:06 ` [PATCH v1 0/3 CHIP: Support vendor script libraries Ulf Samuelsson
2023-03-15 16:27 ` Michael Matz
2023-03-15 20:03 ` Ulf Samuelsson
2023-03-16 8:23 ` Jan Beulich
2023-03-16 10:25 ` Ulf Samuelsson
2023-03-16 15:05 ` Michael Matz [this message]
2023-03-16 15:57 ` Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.2303161417370.16810@wotan.suse.de \
--to=matz@suse.de \
--cc=binutils@emagii.com \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).