This is an archive of the discontinued LLVM Phabricator instance.

Drop Windows support from libFuzzer tests
ClosedPublic

Authored by george.karpenkov on Aug 1 2017, 7:04 PM.

Diff Detail

Event Timeline

kcc edited edge metadata.

I don't mind, but please let Zack or Reid review this.
The question is: do we need to remove all traces of windows support from tests, or just disable check-fuzzer on the bot and remove only the parts that are blocking the refactoring.

rnk edited edge metadata.Aug 2 2017, 10:54 AM

First we should remove check-fuzzer from sanitizer-windows. That means patching zorg and a buildmaster restart. Otherwise, the bot will go red because of a missing target.

@rnk That's nothing I could do, right?
In any case, if we were to leave Windows support, I think redefining CMAKE_CXX_LINK_EXECUTABLE is definitely not the way to go.
It already caused a few problems (e.g. having to change the output directory), and will cause more.
If anything, even moving the compilation to LIT, so that the driver would be able to insert the appropriate libraries, is better.

kcc added a comment.Aug 2 2017, 11:04 AM

Is there an option to make check-fuzzer a no-op on windows?
This way we won't have to touch the bot (and then touch it again, when windows is reinstated)

@kcc of course anything is possible. Should we though? Pretending that tests pass when they don't seems like a bad idea.

rnk added a comment.Aug 2 2017, 11:09 AM

@rnk That's nothing I could do, right?
In any case, if we were to leave Windows support, I think redefining CMAKE_CXX_LINK_EXECUTABLE is definitely not the way to go.

Why do you think that? If we want to keep the logic of where clang's compiler-rt libraries are within the clang driver, this is what we have to do. Otherwise we have to duplicate the logic that -fsanitize=foo uses to find clang's builtin libraries.

Which do you guys prefer, duplication or this complicated CMake logic to make Windows appear more like Posix?

It already caused a few problems (e.g. having to change the output directory), and will cause more.

I'm not familiar with this, you probably explained it somewhere else but I haven't had time to read.

If anything, even moving the compilation to LIT, so that the driver would be able to insert the appropriate libraries, is better.

That would be nice, it would make libFuzzer tests look more like compiler-rt sanitizer tests.

kcc added a comment.Aug 2 2017, 11:09 AM

We will have to do something of this sort anyway once we make 'check-fuzzer' a part of 'check-all' on Linux and Mac.

rnk added a comment.Aug 2 2017, 11:10 AM

@rnk That's nothing I could do, right?

We have to wait for Galina to do master restarts, but the logic is probably pretty easy to remove from zorg/zorg/buildbot/builders/SanitizerBuilderWindows.py.

@rnk

That would be nice, it would make libFuzzer tests look more like compiler-rt sanitizer tests.

I think so too, I've just written an email arguing for it.

Which do you guys prefer

I prefer moving compilation commands to LIT.
Unit tests would still remain, but for them I think it's easier to duplicate the logic and specify all the dependencies in CMake, as done already in all sanitizers.

kcc added a comment.Aug 2 2017, 11:20 AM

I prefer moving compilation commands to LIT.

And I actually don't mind.

@kcc Does it mean you would be OK with the change moving the compilation commands to LIT, and only compiling unit-tests in CMake?

@rnk

I'm not familiar with this, you probably explained it somewhere else but I haven't had time to read.

I was referring to https://reviews.llvm.org/D27870

kcc added a comment.Aug 2 2017, 11:27 AM

@kcc Does it mean you would be OK with the change moving the compilation commands to LIT, and only compiling unit-tests in CMake?

Yes. This will be quite a change though

kcc added a comment.Aug 3 2017, 1:22 PM

I would still suggest to make check-fuzzer a no-op on Windows so that we don't need to touch the windows bot configs now.

zturner edited edge metadata.Aug 3 2017, 1:25 PM

Agreed, if both of you are blocked and just need to move on, and there's no definitive timeline for when a master restart will happen, then just making it a no-op until we can get the step actually removed seems like an immediate way to get unblocked.

@kcc Getting back to this revision, can this be committed as well then?

kcc accepted this revision.Aug 3 2017, 5:26 PM

LGTM

This revision is now accepted and ready to land.Aug 3 2017, 5:26 PM

OK great will probably land after https://reviews.llvm.org/D36295 to avoid conflicting with myself

This revision was automatically updated to reflect the committed changes.