Re: [PATCH v2 2/2] Add scripts/oss-fuzz/build.sh

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,23 @@
> > +#!/bin/bash -eu
> > +# SPDX-License-Identifier: Apache-2.0
>
> Hmm. Aiui this line is supposed to make unnecessary ...
>
> > +# Copyright 2024 Google LLC
> > +#
> > +# Licensed under the Apache License, Version 2.0 (the "License");
> > +# you may not use this file except in compliance with the License.
> > +# You may obtain a copy of the License at
> > +#
> > +#      http://www.apache.org/licenses/LICENSE-2.0
> > +#
> > +# Unless required by applicable law or agreed to in writing, software
> > +# distributed under the License is distributed on an "AS IS" BASIS,
> > +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > +# See the License for the specific language governing permissions and
> > +# limitations under the License.
>
> ... all of this text, provided an entry is first put in ./LICENSES/.
>
> > +################################################################################
> > +
> > +cd xen
>
> This looks to suggest that the expectation is for the script to be invoked
> from the root of a xen.git clone. Imo something like
>
> cd $(dirname $0)/../../xen
>
> would be more flexible.

No, it will be invoked after a git clone is made, so you have to enter
the xen folder that was just cloned.

>
> > +./configure --disable-stubdom --disable-pvshim --disable-docs --disable-xen
>
> Going forward we mean to no longer bundle e.g. qemu in release tarballs,
> yet I wonder whether passing a couple of --with-system-...= here wouldn't
> be better nevertheless.

It largely doesn't matter as long as the configure script completes
successfully since we aren't going to compile QEMU. But sure, I can
add it.

>
> > +make clang=y -C tools/include
> > +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness
>
> In how far is it a requirement to have "clang=y" here? Wasn't this question
> even asked before? I'm not even sure whether mid- or long-term we mean to
> retain that functionality. Overrides of tool chain (components) may better
> be done using CC= and friends. Plus perhaps by whoever is invoking this
> script?

It is an absolute requirement to use clang=y here as oss-fuzz uses a
specific clang as compiler for C/C++ projects. The CC environment
variables are already set by the oss-fuzz docker environment but it's
insufficient for a successful clang build. Without clang=y the
following error is encountered:

gcc: error: unrecognized debug output level 'line-tables-only'
gcc: error: unrecognized argument to '-fsanitize=' option: 'fuzzer-no-link'

Tamas