From: Peter Korsgaard <peter@korsgaard.com>
To: Romain Naour <romain.naour@smile.fr>
Cc: Romain Naour <romain.naour@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/busybox: disable stack optimization for i386 target
Date: Mon, 12 Jun 2023 22:16:47 +0200 [thread overview]
Message-ID: <875y7szb9s.fsf@48ers.dk> (raw)
In-Reply-To: <628684a7-6ad9-1055-ad0b-065761105349@smile.fr> (Romain Naour's message of "Wed, 10 May 2023 12:06:27 +0200")
>>>>> "Romain" == Romain Naour <romain.naour@smile.fr> writes:
> Hello Thomas, All,
> Le 11/02/2023 à 11:10, Romain Naour a écrit :
>> Hello Thomas,
>>
>> Le 11/02/2023 à 10:49, Thomas Petazzoni via buildroot a écrit :
>>> On Sat, 11 Feb 2023 00:36:58 +0100
>>> Romain Naour <romain.naour@gmail.com> wrote:
>>>
>>>> The toolchain-builder project reported an issue with Qemu 7.2.0 for
>>>> x86-core2--glibc--bleeding-edge toolchain [1]:
>>>>
>>>> Run /sbin/init as init process
>>>> random: fast init done
>>>> EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended
>>>> EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
>>>> Starting syslogd: OK
>>>> traps: syslogd[52] general protection fault ip:b7e21465
>>>> sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000]
>>>> Starting klogd: OK
>>>> traps: klogd[56] general protection fault ip:b7e94465
>>>> sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000]
>>>> Running sysctl: traps: logger[62] general protection fault
>>>> ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000]
>>>> Segmentation fault
>>>> traps: logger[64] general protection fault ip:b7dd3b6c
>>>> sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000]
>>>> Segmentation fault
>>>>
>>>> (Followed by a kernel panic.)
>>>>
>>>> Testing with the pevious Qemu release (7.1.0) allows to boot the
>>>> system without any problem.
>>>>
>>>> Building qemu sources between 7.1.0 and 7.2.0 allows to identify
>>>> the first "bad" commit [2] and
>>>> report to the Qemu project [3].
>>>>
>>>> Thanks to Qemu maintainers review, several issues was noticed:
>>>>
>>>> "The default i386 busybox build config does not respect glibc's
>>>> requirements around stack alignment
>>>> (see [4] for previous discussions and a workaround)."
>>>>
>>>> Disabling CONFIG_STACK_OPTIMIZATION_386 option (as suggested in
>>>> the Gentoo bug report) fixed the issue!
>>>>
>>>> This option has been added and enabled by default in buxybox
>>>> 1_29_0, so it was used since then the for
>>>> Buildroot's qemu defconfig.
>>>>
>>>> Note: The x86-i686--glibc--bleeding-edge (generic x86) doesn't trigger the issue with
>>>> CONFIG_STACK_OPTIMIZATION_386 enabled.
>>>>
>>>> Fixes:
>>>> https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
>>>>
>>>> [1] https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
>>>> [2] https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
>>>> [3] https://gitlab.com/qemu-project/qemu/-/issues/1478
>>>> [4] https://bugs.gentoo.org/725674
>>>
>>> Thanks a lo for the great investigation. Do we understand precisely
>>> what is happening? The link at [4] does not really have an explanation,
>>> it only has experimental observations that lead to the conclusion that
>>> disabling CONFIG_STACK_OPTIMIZATION_386 is a work-around, but it does
>>> not really explain what is happening.
>>
>> Actually there are two different issues that contribute to this issue:
>>
>> 1) An existing latent Busybox bug on i386 (busybox compiled with
>> -mpreferred-stack-boundary=2)
>>
>> https://lists.debian.org/debian-boot/2018/01/msg00352.html
>>
>> 2) A Qemu improvement that trigger an exception on unaligned memory accesses
>> that require 16-byte alignment.
>>
>> https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
>>
>> I didn't digging further the root cause of the issue.
> Several bug report are confirming a stack problem due to the i386 GCC ABI which
> assumes the stack is 16-byte aligned [1] [2]. The gcc's default ABI for
> i386-linux-gnu was quietly changed [3] (maybe between gcc 9 and gcc 10).
> Note: When the option was added to Busybox and enabled by default, the help text
> explains that this option may not work with some libc versions:
> "This option makes for smaller code, but some libc versions
> do not work with it (they use SSE instructions without
> ensuring stack alignment)."
> This problem break the test of the x86 core2 toolchain on toolchain-builder.
> [1] https://bugs.gentoo.org/725674#c30
> [2] https://lists.debian.org/debian-boot/2018/01/msg00352.html
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886506;msg=97
> [4]
> https://git.busybox.net/busybox/commit/?id=2c9970281083a99acfa3aec8c6d41db955cb583d
Committed to 2023.02.x, thanks.
--
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-06-12 20:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 23:36 [Buildroot] [PATCH] package/busybox: disable stack optimization for i386 target Romain Naour
2023-02-11 9:49 ` Thomas Petazzoni via buildroot
2023-02-11 10:10 ` Romain Naour
2023-05-10 10:06 ` Romain Naour
2023-06-12 20:16 ` Peter Korsgaard [this message]
2023-05-11 20:44 ` Yann E. MORIN
2023-05-11 20:49 ` Yann E. MORIN
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=875y7szb9s.fsf@48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@buildroot.org \
--cc=romain.naour@gmail.com \
--cc=romain.naour@smile.fr \
--cc=thomas.petazzoni@bootlin.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