LLVM compatibility policy about symcc HOT 6 OPEN

If I understand the FuzzBench configuration correctly, they use a fork by AdaLogics. The fork doesn't seem to follow our changes, so I'm not sure whether we would actually break anything by dropping support for old LLVM versions. However, it still seems a good idea to stay compatible with the FuzzBench base image so that people can use our version of SymCC in FuzzBench if they want. The base image uses Ubuntu 20.04, so we may have to keep LLVM 12 in the list of supported versions until FuzzBench moves to Ubuntu 22.04.

from symcc.

Hi Sebastian,

you are right it's not needed, and painful, to keep compatibility with all LLVM versions.
I like the idea to keep compatibility with the last 2 Ubuntu LTS versions, but keeping last 3 LLVM versions does not guaranty this... Also some people may run Debian stable which is at version 11 (although LLVM provides some package, I don't know if they introduce some issues).

How about we keep 3 LLVM versions but when we drop the support for an Ubuntu LTS+debian stable we make a branch for this version ?
This will potentially make life easier to anyone who needs a specific compatibility (like if SymCC is combined with another tool that doesn't support up to date LLVM). We can put a warning that the branch is for convenience, without any guaranty/support, and only accept some pull requests proposing backports from main branch that pass CI tests (with specific distribution in the CI).
Or will this be too much overhead?

from symcc.

I like the idea of marking the last commit that is compatible with a given LLVM version. But I think you might be right that a dedicated branch with backports will cause a lot of overhead. Shall we just put a label on the commit? It shouldn't be a huge problem for people to build Clang from source if they need or want to stay on an old operating system for some reason.

from symcc.

I like the idea of marking the last commit that is compatible with a given LLVM version. But I think you might be right that a dedicated branch with backports will cause a lot of overhead. Shall we just put a label on the commit? It shouldn't be a huge problem for people to build Clang from source if they need or want to stay on an old operating system for some reason.

OK for me !

Aurélien

from symcc.

I strongly agree that trying to maintain support for ever-changing LLVM APIs is a losing battle.

I don't have much to add, but is maintaining fuzzbench support important to symcc? I say this because it is by far the most commonly used fuzzing benchmark, so ensuring compatibility seems important (eg for building and expanding on symcc, and evaluating their fuzzers against symcc). I note that currently fuzzbench uses a symcc fork. I have no idea how much work this would involve, but potentially something to think about.

from symcc.

That's a good point. I'm not sure how much the fork has diverged, but I'll have a look to see which base image is used there.

from symcc.