[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Date: Thu, 18 Jul 2024 09:29:11 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=tklengyel.com; spf=pass smtp.mailfrom=tamas@xxxxxxxxxxxxx; dmarc=pass header.from=<tamas@xxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1721309390; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=UCUI3K0rUfwvjg2A23hId1M7TJ1G+zKDt+3xFAr6dtc=; b=O2YKqyqqm+0W7VqZevgWowtvyUk6wiS5OXOKdMmu6Bdysgq0/j7TY5+3FFaBxWiERLXyrpjbOAqliHGnKt3GnYh30OnNCUy+duog6HeB9flaKK44GJH3E4k/3u7eRwvJzMXUiH36ipAVVpLsR1O5FZXAsyVicwNiZaPdQ0IvgXA=
  • Arc-seal: i=1; a=rsa-sha256; t=1721309390; cv=none; d=zohomail.com; s=zohoarc; b=cZ23MYKavM1RJMiGwa1msFpgkXlp661KvmA6cGN3zRQ4u87gHGWf+4++UlAgdz8rUAOlrnK8WWUeFadQTuBYjlMdAi6lSWxj4Av+WTrOtqXPO6ySZXRI7Hjg7oEIRav+DxFxuobJ83V4N+92LJReJ6ZsNrbi79uAokJwNdRURFQ=
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 18 Jul 2024 13:30:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Jul 18, 2024 at 9:03 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 18.07.2024 14:54, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> >>> +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.
>
> Yet the suggested alternative would still work then, wouldn't it? And
> it would permit easier use of the script from outside of that very
> specific environment, e.g. when wanting to re-invoke it without
> running a full cloning process every time.

This script is specifically made for that one environment and is not
intended to be invoked from anywhere else. I don't think we need to
complicate this needlessly.

>
> >>> +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'
>
> Could you add a sentence to this effect to the description?

Sure.

Thanks,
Tamas



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.