[PATCH] [LLVM] [sanitizer] add conditionals for libc
tobias at grosser.es
Wed Apr 23 04:34:28 PDT 2014
On 23/04/2014 13:11, Bernhard Reutner-Fischer wrote:
> On 23 April 2014 12:45, Kostya Serebryany <kcc at google.com> wrote:
>> On Wed, Apr 23, 2014 at 2:38 PM, Bernhard Reutner-Fischer
>> <rep.dot.nop at gmail.com> wrote:
>>> On 23 April 2014 10:57, Kostya Serebryany <kcc at google.com> wrote:
>>> These things (e.g. glob_t members) do not change between glibc-releases,
>>> i fail to see how this would be costly to maintain? It's pretty much a
>>> thing to do IMO.
>>>> So, before we continue with review I would like to hear the motivation
>>> The motivation behind this patch is that there are libc's apart from
>>> glibc, and
>>> these libc implementations, being POSIX compliant, may lack certain GNU
>>> extensions (as implemented in glibc). As you can see in your own code, you
>>> have gazillions of conditionals (preprocessor conditionals, which i add
>>> just add
>>> a couple of more, generic ones, btw, to answer your comment from above) to
>>> handle these other libc's.
>> Ok. What particular libc implementation are you trying to use?
> I'm targeting uClibc.
>> And what particular tool are you trying to use (asan, tsan, msan)?
> When bootstrapping GCC the build fails IIRC in asan.
>> Most of the things you hide under ifdefs are important only/mostly for msan,
>> which does not exist in the GCC variant anyway.
>>> The route this patch takes it to probe these non-standard things and
>>> act accordingly.
>>>> whether you are welling to help us maintain this code in future (= set
>>>> up a public build bot)
>>> I'm certainly willing to help maintain this code in the future since i
>>> want to use
>>> your nice sanitizers via gcc, sure. I cannot, however, setup a public
>>> build-bot since
>>> my notebook is not prepared to handle this task on a regular basis.
>>> If you break stuff upstream and i find the backported gcc version to
>>> be dysfunctional, i
>>> will send you fixes if time permits.
>> This round trip has very long latency and brings heavy burden on us (code
> I do not really understand where you see this heavy burden or a burden
> at all TBH.
> If you break my bootstrap with my libc then i'll fix it up, it will
> not affect you folks at
>> 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.
You might be able to set up such a buildbot on the LLVM compile farm.
More information about the llvm-commits