<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> Are you saying that asan works with uClibc with your patches? Good to know!<br>
> Or it just builds?<br>
<br>
</div></div>I did not complete my testing so for a start i'll just say that it builds.<br></blockquote><div><br></div><div>Beware that asan is a *very* platform dependent beast. tsan/msan/lsan -- even more so. </div>
<div>It will most likely not work with a new libc implementation out of the box and build failures is the least of concerns. </div><div>I would prefer if you first make sure that at least basic asan tests work before submitting any changes. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">>> > We are very reluctant to pay this price.<br></div><div class="">
>> > Having a public bot for llvm upstream code will reduce this cost.<br>
>><br>
>> If you can provide a box where i can setup cross-compilers to act as<br>
>> build-bots then that'd be doable, yes.<br>
>><br>
>> I personally do not have such a computer, unfortunately.<br>
><br>
><br>
> Well, this is you who want these patches in, not us. Right?<br>
<br>
</div>Yes, it would be nice to be able to use your sanitizer on more platforms, sure.<br>
But i was not aware that you *require* public build-bots to be provided by<br>
contributors. I read the wiki page to state that it would be nice to have a bot,<br>
not being a requirement for patch-acceptance.<br></blockquote><div><br></div><div>We do not *require* bots. We just want them very very much. </div><div>The more complex is the patch the more we want the bot.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> Second, the build should not require any additional -DHAVE_BLAH -- all this<br>
> logic should be done inside the sources (e.g.<br>
> sanitizer_common/sanitizer_platform.h)<br>
> We should not do any probes at build time<br>
<br>
</div>Not probing at build time will not work, i fear. I cannot determine<br>
the characteristics<br>
of the target otherwise:<br>
How do you suggest can i determine if e.g. netrom/netrom.h exists<br>
otherwise? I cannot.<br></blockquote><div><br></div><div>Check some macro defined by uClibc and its version. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As an alternative to the -DHAVE_BLAH on the command-line, i can use a<br>
cmake "configure_file", see<br>
<a href="http://reviews.llvm.org/D3464#20ab9453" target="_blank">http://reviews.llvm.org/D3464#20ab9453</a></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
What do you think?<br></blockquote><div><br></div><div>That's the same, it will require changes in other build systems. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
><br>
> Then, please follow the code style around (e.g. no /**/ comments)<br>
<br>
</div>oops, i'll fix the comments in c++ code, sorry for that.<br>
<div class="">><br>
> Is nanosleep always available? Is so, just replace usleep with nanosleep w/o<br>
> any more ifdefs.<br>
<br>
</div>nanosleep is required by POSIX1.2008, yes.<br>
<br>
thanks,<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
>><br>
>><br>
>> > Depending on your actual needs (see above) we might be able to do<br>
>> > something<br>
>> > *much* simpler.<br>
>><br>
>> The patch probes for very small, distinct aspects of GNU-extensions of<br>
>> POSIX<br>
>> functions and disables them on an individual basis, reducing long-term<br>
>> maintenance<br>
>> cost by adopting to different target-platforms seamlessly in<br>
>> established manner (by<br>
>> using autoconf resp. existing cmake Modules that are maintained in<br>
>> cmake/autoconf<br>
>> upstream projects) instead of hard-coding meta-knowledge -- like<br>
>> "INTERCEPT_FUNCTION_LINUX_OR_FREEBSD" or "(SI_MAC && !SI_IOS) ||<br>
>> SI_LINUX_NOT_ANDROID".<br>
><br>
><br>
> asan sources are build by *many* different build systems: two (!) in LLVM,<br>
> one in GCC and a few proprietary.<br>
> So, we do not want any autoconf-style checks at build time.<br>
><br>
> --kcc<br>
><br>
>><br>
>><br>
>> If you have a better idea or simpler idea then i'm all ears :)<br>
>><br>
>> thanks,<br>
>> ><br>
>> > --kcc<br>
>> ><br>
>> >><br>
>> >> please let me<br>
>> >> know if you have specific<br>
>> >> questions about a technical aspect of the patch.<br>
>> >><br>
>> >> Please apply.<br>
>> >> thanks,<br>
>> >> ><br>
>> >> > <a href="http://reviews.llvm.org/D3464" target="_blank">http://reviews.llvm.org/D3464</a><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>