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

Mark Deric codetech at dericnet.com
Wed Jul 17 07:01:56 PDT 2013 

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>

More information about the cfe-dev mailing list