On 29 March 2018 at 07:00, Tomasz Torcz <tomek@xxxxxxxxxxxxxx> wrote: > March 29, 2018 12:06 PM, "Peter Robinson" <pbrobinson@xxxxxxxxx> wrote: > >> On Thu, 29 Mar 2018, 16:24 Florian Weimer, <fweimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
