Re: [Buildroot] [PATCH next 1/1] package/kexec: fix link error when BR2_OPTIMIZE_0=y

[Julien Olivain <ju.o@free.fr>]

Hi Thomas,

On 22/08/2023 21:35, Thomas Petazzoni wrote:
> On Tue, 22 Aug 2023 21:23:14 +0200
> Julien Olivain <ju.o@free.fr> wrote:
> 
>> When BR2_OPTIMIZE_0, -O0 is passed in compiler CFLAGS. This means no
>> code optimization will be performed.
>> 
>> kexec code uses a trick to detect unaligned accesses at link time
>> which needs at least dead-code-removal to work. See
>> put/get_unaligned() macros in kexec/kexec.h. This code was re-enabled
>> in upstream commit [1].
>> 
>> This commit sets at least -O1 (which include the sufficient
>> dead-code-removal) when BR2_OPTIMIZE_0=y, to fix those issues.
>> 
>> Fixes:
>> - 
>> http://autobuild.buildroot.org/results/8f8/8f8532f1dfbd71e52c51c00118934af9fa45e7cb
>> - 
>> http://autobuild.buildroot.org/results/528/528fd7baf9b0ad5549d22ec8e0623c5fa1f2d117
>> - 
>> http://autobuild.buildroot.org/results/499/499115439680adfb4b40042468e5bbb65d91ce6c
>> - ...and many others
>> 
>> [1] 
>> https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=0723defb5308ac7fce296f8b596bff4df6803f01
>> 
>> Signed-off-by: Julien Olivain <ju.o@free.fr>
>> ---
>> Patch tested on branch next at commit bfa4a7c with commands:
> 
> Thanks for the research, but why is this tagged for next? You're saying
> the issue was introduced in kexec-tools commit
> 0723defb5308ac7fce296f8b596bff4df6803f01, and this commit was initially
> part of the 2.0.1 release of kexec-tools, which we have in Buildroot
> since February 2010.
> 
> Based on that, I would have expected this patch to be relevant for our
> master branch, but you explicitly say it should be merged in next,
> which to me doesn't make sense. Could you clarify?

This could indeed go into the master branch. Since 2023.08-rc2 was
already tagged, I imagined only major fixes would go into master.
This one has been longstanding issue (so apparently not so important).

In fact, reading the Buildroot documentation release engineering at [1]
does really allow me to decide what kind of commits (security, bugfixes,
new features, minor improvements like typos) should go to master/next.

Recently, I had the same interpretation in [2] that a minor improvement
(in which nothing was actually broken) should go to next. Yann preferred
master.

If you summarize those situations, I would be happy to propose a doc
improvement.

> Thanks a lot!
> 
> Thomas

[1] https://nightly.buildroot.org/manual.html#_development
[2] 
https://lists.buildroot.org/pipermail/buildroot/2023-August/672866.html

Best regard,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot