On Tue, Dec 3, 2013 at 5:42 PM, Jeff Law <l...@redhat.com> wrote: > On 12/03/13 08:47, Jakub Jelinek wrote: >> >> On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote: >>>>>> >>>>>> No, so your patch doesn't regress anything. I can configure with >>>>>> --disable-libsanitizer to skip build of libsanitizer, although it >>>>>> would be nice to support RHEL5 derived long-term distributions. >>>>> >>>>> Ok, so this does not gate the merge. >>>> >>>> >>>> Well, it regresses against 4.8, so it still is a P1 regression. >>> >>> >>> Does anyone care? >> >> >> Of course. First of all all users trying to compile gcc just to find out >> it won't build out of the box. Also users that were using asan just fine >> on older platforms in gcc 4.8 and now they'll find out that the support >> has been dropped. > > Right. We certainly care. Those old platforms are still in widespread use > (for better or worse).
So, would you be able to help us upstream? We need a) patches that we can review and apply to the llvm repository (w/o breaking the modern systems, of course) b) a buildbot that would run 24/7 catching regressions. If we reach a green state for a platform X and have a buildbot for it, keeping it green will require relatively small effort. Every time we break it we will notice it in minutes and fix quickly while we still have the same context fresh. Fixing old systems once in few months during merge to gcc is costly because failures accumulate. --kcc > > >> >>> Maintaining asan&co on older platforms has a cost, and we are not >>> willing to pay it; >> >> >> Well, but then you just get approximately same cost if not higher in >> maintaining configure bits for checking all the silent assumptions the >> code >> makes and disabling libsanitizer in that case. > > Right. Fixing this problem and fixing it correctly will reduce the long > term pain for both projects. > > > >>> >>> This won't happen any time soon, right? >>> I'd like to ask glibc for many other things, not just this, but the >>> latency >>> of the glibc changes propagating to users is too low, so we don't >>> bother (although we should) >>> E.g. we've been hit by the ugly >>> pthread_getattr_np/pthread_attr_getstack multiple times. >>> :( >> >> >> If you never ask for it, it will never be done, it is that simple. > > glibc pushes out a release every six months which then gets put into the > next Fedora release which usually follows a few months later. We're talking > about a worst case lag time of roughly 9 months, often much less. It's > probably similar for the SuSE community releases. > > I think everyone who has had a bad experience working with glibc's team in > the past should try to put it behind them. The new team running glibc is > much more reasonable to work with -- the biggest problem now is rebooting > the project after years of mis-management. The progress they've made > towards that over the last year has been tremendous. > > jeff > >
