From: Peter Korsgaard <peter@korsgaard.com>
To: <yann.morin@orange.com>
Cc: <buildroot@buildroot.org>, Romain Naour <romain.naour@gmail.com>,
Giulio Benetti <giulio.benetti@benettiengineering.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [Buildroot] [PATCH 2/3] toolchain/wrapper: check we did not add more args than expected
Date: Sun, 18 May 2025 14:51:24 +0200 [thread overview]
Message-ID: <87wmaeqdyr.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <e4024c6c1e1825bd52ab14faafbc7655d3074eb3.1723543467.git.yann.morin@orange.com> (yann morin's message of "Tue, 13 Aug 2024 12:04:30 +0200")
>>>>> <yann.morin@orange.com> writes:
> From: "Yann E. MORIN" <yann.morin@orange.com>
> We have a hard-coded constant that defines how many expected args we may
> conditionally add at most, but it is very easy to miss updating that
> when adding new conditional args.
> Add a check that we did not overshoot the allowance.
> Ideally, we would have a nice way to add to, and extend the *args array
> dynamically, but this would be quite costly, while the wrapper is a hot
> path to the compiler. So, this test is a better solution in the end: it
> is simple and cheap.
Costly? It would just be a realloc call, and the list of argument
pointers is not very long, so I doubt it would be noticable compared to
all the argument parsing and finally running the real compiler.
In fact, I think it would make more sense to get rid of our
EXCLUSIVE_ARGS constant and just allocate room for E.G. 1024 arguments
and then just realloc in the special cases where that is not enough.
I've sent a small series doing that here:
https://patchwork.ozlabs.org/project/buildroot/patch/20250518124949.4159568-2-peter@korsgaard.com/
--
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-05-18 12:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 10:04 [Buildroot] [PATCH 0/3] toolchain/wrapper: move -ztext to the toolchain wrapper yann.morin
2024-08-13 10:04 ` [Buildroot] [PATCH 1/3] toolchain/wrapper: check unsafe paths earlier yann.morin
2025-05-18 9:52 ` Peter Korsgaard
2025-06-04 18:20 ` Arnout Vandecappelle via buildroot
2024-08-13 10:04 ` [Buildroot] [PATCH 2/3] toolchain/wrapper: check we did not add more args than expected yann.morin
2025-05-18 12:51 ` Peter Korsgaard [this message]
2024-08-13 10:04 ` [Buildroot] [PATCH 3/3] toolchain/wrapper: move -ztext from LDFLAGS to toolchain wrapper yann.morin
2024-08-14 5:54 ` yann.morin
2024-08-23 11:02 ` [Buildroot] [PATCH 0/3] toolchain/wrapper: move -ztext to the " J. Neuschäfer via buildroot
2024-09-13 17:06 ` Markus Mayer via buildroot
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=87wmaeqdyr.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@buildroot.org \
--cc=giulio.benetti@benettiengineering.com \
--cc=romain.naour@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=yann.morin@orange.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.