[cfe-dev] CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric codetech at dericnet.com
Sat Aug 17 22:43:04 PDT 2013 

Hi Evgeniy,

Now my apologies for being late; the day job's been pretty consuming but maybe I'm on the good side.  I'll look at the platform_limits files and see if I can help.

I'll keep you posted.

Thank you.

Mark


On Tue, 30 Jul 2013 15:16:42 +0400
Evgeniy Stepanov <eugenis at google.com> wrote:

> Hi,
> 
> sorry for the late response. First of all, any configure magic would
> need to be replicated in cmake, as we have two build systems. That's
> part of the reason we tend to do as much as possible right in the
> source code.
> 
> I wonder if you could find out the minimal change to platform_limits
> files to make them compile on your OS?
> 
> On Thu, Jul 18, 2013 at 10:37 AM, Mark Deric <codetech at dericnet.com> wrote:
> > Thanks, Alexey.
> >
> > I would reiterate my willingness to put a piece of a modest RHEL5 machine in place as a buildbot slave if you could point me to the right person to get around the "builds now" requirement.  Hey, it's not just a 286, it has a great V35 modem capable of 56 kilobaud!  And I would have worked on finding some ac_helpful.m4 on mroute.h but, just as I was shutting down the fryer at my day job, this soccer team comes in ordering 31 super size.  Hate it when that happens.
> >
> > On Wed, 17 Jul 2013 18:18:23 +0400
> > Alexey Samsonov <samsonov at google.com> wrote:
> >
> >> I see your point. We'll try to add header detection to our build system
> >> soon.
> >>
> >>
> >> On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <codetech at dericnet.com> wrote:
> >>
> >> > Kernel is pretty old, but it's the core of a wildly popular RHEL5
> >> > distribution that's still getting kernel updates (i.e.,
> >> > kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of
> >> > 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion
> >> > period.  So, my guess is that RHEL5 will represent widespread active
> >> > production machines for at least the next 24 months.
> >> >
> >> > On the "do I use sanitizers" question, the answer is not explicitly and/or
> >> > not yet, being new to Clang.  I only use the compiler now, but I want to
> >> > use static analyzer and other llvm code quality tools as I find them, and
> >> > play with formatter.  The problem I had was even compiler would not build
> >> > following the basic instructions with the mroute6?.h headers.
> >> >
> >> > Conceptually, if there's a code bit that drills into headers for very
> >> > platform specific things like ioctl, using autotool-like detection or
> >> > support of a narrowed platform set seems like a real design choice.  In the
> >> > event of picking the latter, maybe the top level build instructions should
> >> > provide a way to unplug "sanitizer" so the compiler itself can enjoy an
> >> > wider target range?
> >> >
> >> > Thank you.
> >> >
> >> > Mark
> >> >
> >> > On Wed, 17 Jul 2013 17:29:40 +0400
> >> > Alexey Samsonov <samsonov at google.com> wrote:
> >> >
> >> > > Looks like 2.6.18 kernel is pretty old... Mark, do you actually plan to
> >> > use
> >> > > sanitizers? We consider dropping support for old kernels to ease the
> >> > > maintenance.
> >> > > Seems that with all the recent ioctl hackery we'll need to add support
> >> > for
> >> > > detecting Linux kernel version and headers availability to our build
> >> > > system...
> >> > >
> >> > >
> >> > > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <kcc at google.com>
> >> > wrote:
> >> > >
> >> > > > +samsonov
> >> > > >
> >> > > >
> >> > > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <codetech at dericnet.com
> >> > >wrote:
> >> > > >
> >> > > >> While the following partial patch may not be the best approach, it
> >> > solves
> >> > > >> the compiler build failure problem on RHEL 5 in my sandbox (and
> >> > probably
> >> > > >> for any Linux 2.x kernel at or before 2.6.18).  Ultimately, maybe we
> >> > should
> >> > > >> avoid holding a compiler build hostage to incompatible TCP/IP headers
> >> > in a
> >> > > >> target/build host's distribution?
> >> > > >>
> >> > > >> Also, is there an easy way to find out if there's a buildbot slave
> >> > > >> running RHEL5 w/gcc 4.8.1? I waded through some clicks off of
> >> > > >> http://lab.llvm.org:8011/buildslaves, but it wasn't obvious and I
> >> > > >> thought there must be an easier, better way?  I could volunteer part
> >> > of a
> >> > > >> modest box for that duty since it's dear to my heart.
> >> > > >>
> >> > > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > > >> ===================================================================
> >> > > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > (revision
> >> > > >> 186236)
> >> > > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > (working
> >> > > >> copy)
> >> > > >> @@ -73,8 +73,11 @@
> >> > > >>  #include <linux/if_eql.h>
> >> > > >>  #include <linux/if_plip.h>
> >> > > >>  #include <linux/lp.h>
> >> > > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> >> > > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>  #include <linux/mroute.h>
> >> > > >>  #include <linux/mroute6.h>
> >> > > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>  #include <linux/scc.h>
> >> > > >>  #include <linux/serial.h>
> >> > > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> >> > > >> @@ -279,7 +282,7 @@
> >> > > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> >> > > >>  #endif
> >> > > >>
> >> > > >> -#if !SANITIZER_ANDROID
> >> > > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> >> > > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> >> > > >>  #endif
> >> > > >> @@ -330,7 +333,7 @@
> >> > > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> >> > > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> >> > > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> >> > > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> >> > > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> >> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> >> > > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> >> > > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> >> > > >>  #endif
> >> > > >>
> >> > > >> Needless to say, getting to a good way to set the manifest constant
> >> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18 is still an open question.  I got
> >> > some
> >> > > >> encouragement that there might be a good GNU autotools way to do this
> >> > from
> >> > > >>
> >> > http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html
> >> > ;
> >> > > >> but this is well outside my sweet spot.
> >> > > >>
> >> > > >> Thank you.
> >> > > >>
> >> > > >> Mark
> >> > > >>
> >> > > >>
> >> > > >> On Sat, 13 Jul 2013 15:15:33 -0700
> >> > > >> Mark Deric <codetech at dericnet.com> wrote:
> >> > > >>
> >> > > >> > This is the same issue as reported in the "Trouble compiling CLANG
> >> > on on
> >> > > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.
> >> >  Afaict,
> >> > > >> the
> >> > > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> >> > > >> > [sanitizer] ioctl interceptor"; though that's from code inspection,
> >> > not
> >> > > >> > from having tried the immediate predecessor.  The Clang 3.3
> >> > certainly
> >> > > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> >> > > >> distro's
> >> > > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build
> >> > until 24
> >> > > >> > June and have been getting this bust since then; here's last night's
> >> > > >> try:
> >> > > >> >
> >> > > >> > In file included from
> >> > > >>
> >> > /mnt/share/RHEL5_local/buildroot/llvm_projects/llvm_svn_wtest_20130712_191043/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:76:
> >> > > >> > In file included from /usr/include/linux/mroute.h:5:
> >> > > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> >> > > >> 'IPPROTO_IP'
> >> > > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> >> > > >> */
> >> > > >> >   ^
> >> > > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro
> >> > 'IPPROTO_IP'
> >> > > >> > #define IPPROTO_IP              IPPROTO_IP
> >> > > >> >                                 ^
> >> > > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> >> > > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> >> > > >> >     ^
> >> > > >> >
> >> > > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other
> >> > manifest
> >> > > >> > constants/enums collide in later messages.  Further, if the build
> >> > got by
> >> > > >> > this issue, I think it would land on the rocks again with the
> >> > subsequent
> >> > > >> > include of <linux/mroute6.h> on the next line of
> >> > > >> > sanitizer_platform_limits_posix.cc since that file does not exist
> >> > in the
> >> > > >> > CentOS/RHEL 5 distribution.
> >> > > >> >
> >> > > >> > I did a code check of these headers on Ubuntu 12.04 and the
> >> > organization
> >> > > >> > seems updated and consistent with the compiler-rt sanitizer code.
> >> >  It
> >> > > >> also
> >> > > >> > appears as though there is some effort to do OS/platform detection
> >> > using
> >> > > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But
> >> > these
> >> > > >> are
> >> > > >> > based on things like "#if defined(__linux__)" and do not appear to
> >> > be
> >> > > >> > granular enough to accomodate the header differences among Linux'es.
> >> > > >> >
> >> > > >> > I'm a newbie to building/using and looking at Clang so I don't know
> >> > the
> >> > > >> > idioms for OS/platform detection or the consumer side of sanitizer;
> >> > and
> >> > > >> I
> >> > > >> > suspect fixups in those areas are the right way to address this
> >> > bust.
> >> > > >> >
> >> > > >> > +eugenis following Kostya Serebryany's lead
> >> > > >> >
> >> > > >> > --
> >> > > >> > Mark Deric <codetech at dericnet.com>
> >> > > >> > _______________________________________________
> >> > > >> > cfe-dev mailing list
> >> > > >> > cfe-dev at cs.uiuc.edu
> >> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Mark Deric <codetech at dericnet.com>
> >> > > >> _______________________________________________
> >> > > >> cfe-dev mailing list
> >> > > >> cfe-dev at cs.uiuc.edu
> >> > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Alexey Samsonov, MSK
> >> > >
> >> >
> >> >
> >> > --
> >> > Mark Deric <codetech at dericnet.com>
> >> >
> >>
> >>
> >>
> >> --
> >> Alexey Samsonov, MSK
> >>
> >
> >
> > --
> > Mark Deric <codetech at dericnet.com>


-- 
Mark Deric <codetech at dericnet.com>

More information about the cfe-dev mailing list