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

Alexey Samsonov samsonov at google.com
Wed Jul 17 07:18:23 PDT 2013 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130717/c2537ecb/attachment.html>

More information about the cfe-dev mailing list