On Fri, Aug 30, 2024 at 04:48:37PM -0700, Sami Tolvanen wrote: > Hi Kris, > > On Fri, Aug 23, 2024 at 8:38???PM Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote: > > > > diff --git a/scripts/verify_builtin_ranges.awk b/scripts/verify_builtin_ranges.awk > > new file mode 100755 > > index 000000000000..f513841da83e > > --- /dev/null > > +++ b/scripts/verify_builtin_ranges.awk > > @@ -0,0 +1,356 @@ > > +#!/usr/bin/gawk -f > > +# SPDX-License-Identifier: GPL-2.0 > > +# verify_builtin_ranges.awk: Verify address range data for builtin modules > > +# Written by Kris Van Hees <kris.van.hees@xxxxxxxxxx> > > +# > > +# Usage: verify_builtin_ranges.awk modules.builtin.ranges System.map \ > > +# modules.builtin vmlinux.map vmlinux.o.map \ > > +# [ <build-dir> ] > > While I was testing this, I did an arm64 build and I'm getting a long > list of errors that ends with this: > > ERROR: Failed to read: > ././drivers/firmware/efi/libstub/.lib.a(efi-stub-entry.stub.o.cmd > > Invalid kernel build directory (.) > or its content does not match modules.builtin.ranges > > That path looks a bit funky. Have you tested this with other > architectures? I was able to get this to work on x86 builds just fine. I did test on arm64 and it works perfectly well for me with GNU ld. But I just tested with LLVM (and thus the lld linker map format) and that gave me the same error as you report with the verifier script. Looking into it... Thanks for reporting this! The good news is that it looks like the modules.builtin.ranges data is actually generated correctly. It seems to be just the verifier script that is failing to handle that unusual entry correctly. Kris
