Hmm, does this handle my concern from the last patch. That is, if the
previous script is broken by some change, this will catch it?
If so, should there be a way to run this always? As it looks to be only
used for manual tests.
On Mon, 15 Jul 2024 23:10:44 -0400
Kris Van Hees <kris.van.hees@xxxxxxxxxx> wrote:
> The modules.builtin.ranges offset range data for builtin modules is
> generated at compile time based on the list of built-in modules and
> the vmlinux.map and vmlinux.o.map linker maps. This data can be used
^^
As my daughter keeps reminding me, nobody uses double spaces after a period
anymore ;-)
> to determine whether a symbol at a particular address belongs to
> module code that was configured to be compiled into the kernel proper
> as a built-in module (rather than as a standalone module).
>
> This patch adds a script that uses the generated modules.builtin.ranges
> data to annotate the symbols in the System.map with module names if
> their address falls within a range that belongs to one or mre built-in
"more" ?
> modules.
>
> It then processes the vmlinux.map (and if needed, vmlinux.o.map) to
> verify the annotation:
>
> - For each top-level section:
> - For each object in the section:
> - Determine whether the object is part of a built-in module
> (using modules.builtin and the .*.cmd file used to compile
> the object as suggested in [0])
> - For each symbol in that object, verify that the built-in
> module association (or lack thereof) matches the annotation
> given to the symbol.
>
> Signed-off-by: Kris Van Hees <kris.van.hees@xxxxxxxxxx>
> Reviewed-by: Nick Alcock <nick.alcock@xxxxxxxxxx>
> Reviewed-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
After running this, I do get a lot of messages:
uncore_pmu_event_start in intel_uncore (should NOT be)
uncore_pcibus_to_dieid in intel_uncore (should NOT be)
uncore_die_to_segment in intel_uncore (should NOT be)
uncore_device_to_die in intel_uncore (should NOT be)
__find_pci2phy_map in intel_uncore (should NOT be)
uncore_event_show in intel_uncore (should NOT be)
uncore_pmu_to_box in intel_uncore (should NOT be)
uncore_msr_read_counter in intel_uncore (should NOT be)
uncore_mmio_exit_box in intel_uncore (should NOT be)
uncore_mmio_read_counter in intel_uncore (should NOT be)
uncore_get_constraint in intel_uncore (should NOT be)
uncore_put_constraint in intel_uncore (should NOT be)
uncore_shared_reg_config in intel_uncore (should NOT be)
uncore_perf_event_update in intel_uncore (should NOT be)
uncore_pmu_event_read in intel_uncore (should NOT be)
uncore_pmu_event_stop in intel_uncore (should NOT be)
uncore_pmu_event_add in intel_uncore (should NOT be)
[..]
usb_debug_root in usb_common (should NOT be)
usb_hcds_loaded in usbcore (should NOT be)
iTCO_vendorsupport in iTCO_vendor_support (should NOT be)
snd_ecards_limit in snd (should NOT be)
snd_major in snd (should NOT be)
snd_oss_root in snd (should NOT be)
snd_seq_root in snd (should NOT be)
ip6_min_hopcount in ipv6 (should NOT be)
ip6_ra_chain in ipv6 (should NOT be)
raw_v6_hashinfo in ipv6 (should NOT be)
Verification of /work/build/nobackup/debiantesting-x86-64/modules.builtin.ranges:
Correct matches: 24962 (75% of total)
Module matches: 0 (0% of matches)
Mismatches: 8262 (24% of total)
Missing: 0 (0% of total)
What does this mean?
-- Steve
> ---
>
> Notes:
> Changes since v4:
> - New patch in the series
>
> scripts/verify_builtin_ranges.awk | 348 ++++++++++++++++++++++++++++++
> 1 file changed, 348 insertions(+)
> create mode 100755 scripts/verify_builtin_ranges.awk
>
> diff --git a/scripts/verify_builtin_ranges.awk b/scripts/verify_builtin_ranges.awk
> new file mode 100755
> index 000000000000..a2475a38ba50
> --- /dev/null
> +++ b/scripts/verify_builtin_ranges.awk
> @@ -0,0 +1,348 @@
> +#!/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
> +#
> +
> +# Return the module name(s) (if any) associated with the given object.
> +#
> +# If we have seen this object before, return information from the cache.
> +# Otherwise, retrieve it from the corresponding .cmd file.
> +#
