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 <[email protected]>
> 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 <[email protected]>
> > +#
> > +# 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
