On 29 March 2018 at 07:00, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
March 29, 2018 12:06 PM, "Peter Robinson"
<pbrobinson(a)gmail.com> wrote:
> On Thu, 29 Mar 2018, 16:24 Florian Weimer, <fweimer(a)redhat.com> wrote:
>
>> On 03/28/2018 08:48 PM, Tomasz Torcz 👁️ wrote:
>>
>>>> Note that while GCC produces broken code, this is actually an ABI bug,
and
>>>> we cannot change struct layout rules for long long retroactively. Maybe
we
>>>> could for _Atomic long long, but that would need a lengthy
investigation,
>>>> and I strongly believe that everyone is better off if the time is spent
on
>>>> improving 64-bit architectures.
>>>
>>> Does it mean that the bug was here for the last 23 years? And now this
>>> became a problem?
>>
>> I'm not sure how you came up with the duration. The bug is most
>> certainly much younger than that, probably introduced along with the new
>> atomic intrinsics in a late GCC 4.8.x release. Arguably, it is a real
>> bug only for _Atomic long long members.
>
> Probably referring to the age of the 389-ds code base which dates all the way back to
Netscape
> Directory Server
i686 become available in 1995. The bug in 389ds is serious enough to condemn the whole
architecture, so what exactly happened?
1) 389ds was always broken on i686 (and no-one noticed that before?)
2) there was some code added to 389ds later, code which triggered the bug? (could it be
reverted then?)
3) there was code added to toolchain (GCC) which started producing broken code in 389?
(could the change in GCC be reverted/ repaired?)
4) … ?
Don't get me wrong, I'm not defending i686, it should have been relegated to
the museum long ago. But I feel uneasy when there is some bug marking the whole
architecture as broken. We were running GCC-compiled 389ds on i686 for years, does it mean
we trusted broken code to manage our identity?
My understanding is that the code was rearchitected to use atomic 64
features to avoid deadlocks, corruptions and other things that atomics
are meant to avoid. To undo it would be to revert N months of work and
probably reintroduce whatever 'flaws' that the atomic functions
remove.
On the other hand, it may be that the atomics aren't implemented
correctly on anything but 64 bit architectures (aka they work by luck
on arm32 versus design) so it isn't just i386 which is problematic...
it is just the one it shows up on loudly. [This seems to be what the
gcc maintainers have said.. that unless you force alignment on
specific boundaries you are in undefined behavior]
So to me this isn't as much about i686 being problematic. It is that
32 bit needs to be looked at and most code which is using 64 bit
atomics in 32 bit may need to excludearch to 64 bit only.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.