Hi Arnd Bergmann, > On Tuesday 24 June 2003 02:00, Adam Heath wrote: >> On Tue, 24 Jun 2003, "Martin v. Löwis" wrote: >> > In g++ 3.2, this code was distributed as "i386", and nobody noticed >> > that it doesn't work on i386 for quite some time. In gcc 3.3, an >> > implementation is provided that works on i386, and this >> > implementation here is declared i486. Unfortunately, the two >> > implementations are not binary compatible. Debian has to pick one of >> > these, and it needs to pick the i486 version for compatibility with >> > other Linux distributions (which either ship with gcc 3.2 today, or >> > target i586+ only, anyway). >> >> Er, if this function is inlined, then how can it be part of some >> published api? If it's not part of some published api, then how can >> using an i386 variation cause problems with other distributions? > > The API requires that access to atomic variables is truly atomic. > > The i386 version uses a semaphore to synchronize the access to an atomic > variable, the i486+ version uses the lock prefix. When you mix these two > in one program, two threads might access the variable without locking > against each other because the code inside the semaphore does not lock > the memory bus.
This has been a very informative discussion. While hesitant about dropping i386 support I am now convinced that: (a) i386 support should be dropped so that binary compatibility can be maintained with other Linux distributions. Debian's binary compatibility is a very important feature, especially as a lot of proprietary Linux software companies provide no official support for Debian. Binary compatibility helps fulfil the social contract where "although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages." (b) i486+ should be targeted, but GCC-compiled code optimised for either i586 or i686 (consider whichever is also best for P4 and Athlon). Debian has the goal of being a universal distribution and operating system, and even ditching i386 support is chilling enough. Pragmatically, even though i486 desktops are now relatively scarce i486 laptops still make very useful portable routers. (c) Just keep the i386 name. Changing it will break too many scripts when all that is needed to resolve confusion is a release note. i486+ would still be misleading to those who need to understand that even though i486 is supported the binaries are still optimised for a more recent architecture. One day support for i486 will be dropped and then we also won't need to worry about changing the architecture name. I'd appreciate replies to this message to be CCed to my email address. Regards, Adam
