[cfe-dev] CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers
Mark Deric
codetech at dericnet.com
Wed Jul 17 23:37:07 PDT 2013
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>
More information about the cfe-dev
mailing list