On 18/01/18 23:44, Cyril Brulebois wrote:
> Raphael Hertzog <hert...@debian.org> (2018-01-17):
>> On Wed, 17 Jan 2018, Aurelien Jarno wrote:
>>> busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has
>>> the same effect of reducing the default stack alignment from 16 bytes to
>>> 2 bytes. This comes from arch/i386/Makefile:
>>>
>>> |  # -mpreferred-stack-boundary=2 is essential in preventing gcc 4.2.x
>>> |  # from aligning stack to 16 bytes. (Which is gcc's way of supporting 
>>> SSE).
>>> |  CFLAGS += $(call cc-option,-march=i386 -mpreferred-stack-boundary=2,)
>>>
>>> I don't really get why it is essential to prevent gcc from aligning
>>> stack to 16 bytes, anyway this is a bad idea. Removing this option just
>>> fixes the issue.

Hi all,

I've added the busybox mailing list and Denys Vlasenko. Denys: can you
explain in more detail why this is/was necessary and whether it's
sensible to remove this these days, given the issues it seems to cause?

> Oh wow, that's an old commit:
> | commit 65b8cfb2a0b6854271dbd8baf5203896223cd4ce
> | Author: Denis Vlasenko <vda.li...@googlemail.com>
> | Date:   Mon Jul 23 21:05:06 2007 +0000
> | 
> |     add comment why preferred stack boundary is 4 on i386
> 
>> I confirm that rebuilding busybox with this option dropped fixed the issue
>> for me. I uploaded a fixed busybox to Kali. I'm happy to do the same for
>> Debian if it can help the current maintainers.
> 
> Fixing it ASAP would look good to me (unless you here differently from
> Chris or Christoph); it would be great to ping upstream to propagate
> Aurélien's comments too.

I'd like to get a response from Denys about this first but I don't have
any particular objection to patching this for Debian; I just want to
understand better why this was done upstream before simply reverting it.

We also have a new upstream release of busybox to push into unstable, so
it's tempting to roll this tweak in with that.

Cheers,
Chris

-- 
Chris Boot
bo...@debian.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to