[PATCH] [LLVM] [sanitizer] add conditionals for libc

[Kostya Serebryany]

>
> > Are you saying that asan works with uClibc with your patches? Good to
> know!
> > Or it just builds?
>
> I did not complete my testing so for a start i'll just say that it builds.
>

Beware that asan is a *very* platform dependent beast. tsan/msan/lsan --
even more so.
It will most likely not work with a new libc implementation out of the box
and build failures is the least of concerns.
I would prefer if you first make sure that at least basic asan tests work
before submitting any changes.


> >> > We are very reluctant to pay this price.
> >> > Having a public bot for llvm upstream code will reduce this cost.
> >>
> >> If you can provide a box where i can setup cross-compilers to act as
> >> build-bots then that'd be doable, yes.
> >>
> >> I personally do not have such a computer, unfortunately.
> >
> >
> > Well, this is you who want these patches in, not us. Right?
>
> Yes, it would be nice to be able to use your sanitizer on more platforms,
> sure.
> But i was not aware that you *require* public build-bots to be provided by
> contributors. I read the wiki page to state that it would be nice to have
> a bot,
> not being a requirement for patch-acceptance.
>

We do not *require* bots. We just want them very very much.
The more complex is the patch the more we want the bot.


> > Second, the build should not require any additional -DHAVE_BLAH -- all
> this
> > logic should be done inside the sources (e.g.
> > sanitizer_common/sanitizer_platform.h)
> > We should not do any probes at build time
>
> Not probing at build time will not work, i fear. I cannot determine
> the characteristics
> of the target otherwise:
> How do you suggest can i determine if e.g. netrom/netrom.h exists
> otherwise? I cannot.
>

Check some macro defined by uClibc and its version.


>
> As an alternative to the -DHAVE_BLAH on the command-line, i can use a
> cmake "configure_file", see
> http://reviews.llvm.org/D3464#20ab9453


>
> What do you think?
>

That's the same, it will require changes in other build systems.

--kcc


>
> >
> > Then, please follow the code style around (e.g. no /**/ comments)
>
> oops, i'll fix the comments in c++ code, sorry for that.
> >
> > Is nanosleep always available? Is so, just replace usleep with nanosleep
> w/o
> > any more ifdefs.
>
> nanosleep is required by POSIX1.2008, yes.
>
> thanks,
> >
> >
> >
> >>
> >>
> >> > Depending on your actual needs (see above) we might be able to do
> >> > something
> >> > *much* simpler.
> >>
> >> The patch probes for very small, distinct aspects of GNU-extensions of
> >> POSIX
> >> functions and disables them on an individual basis, reducing long-term
> >> maintenance
> >> cost by adopting to different target-platforms seamlessly in
> >> established manner (by
> >> using autoconf resp. existing cmake Modules that are maintained in
> >> cmake/autoconf
> >> upstream projects) instead of hard-coding meta-knowledge -- like
> >> "INTERCEPT_FUNCTION_LINUX_OR_FREEBSD" or "(SI_MAC && !SI_IOS) ||
> >> SI_LINUX_NOT_ANDROID".
> >
> >
> > asan sources are build by *many* different build systems: two (!) in
> LLVM,
> > one in GCC and a few proprietary.
> > So, we do not want any autoconf-style checks at build time.
> >
> > --kcc
> >
> >>
> >>
> >> If you have a better idea or simpler idea then i'm all ears :)
> >>
> >> thanks,
> >> >
> >> > --kcc
> >> >
> >> >>
> >> >> please let me
> >> >> know if you have specific
> >> >> questions about a technical aspect of the patch.
> >> >>
> >> >> Please apply.
> >> >> thanks,
> >> >> >
> >> >> > http://reviews.llvm.org/D3464
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140423/9fb2456f/attachment.html>