sh: inconsistent kallsyms data

From: Paul Mundt (lethal_at_linux-sh.org)
Date: 12/31/04

  • Next message: Linus Torvalds: "Re: ptrace single-stepping change breaks Wine" 
    Date:	Fri, 31 Dec 2004 19:25:50 +0200
To: linux-kernel@vger.kernel.org

    Building 2.6.10 for sh results in inconsistent kallsyms data. Turning on
    CONFIG_KALLSYMS_ALL fixes it, as does CONFIG_KALLSYMS_EXTRA_PASS.

    The symbols that seem to be problematic between the second and third
    pass are all kallsyms special symbols. With only CONFIG_KALLSYMS set we
    see:

    --- System.map 2004-12-31 10:53:10.278567522 -0600
    +++ .tmp_System.map 2004-12-31 10:53:10.347558024 -0600
    @@ -6868,9 +6868,9 @@
     8817c4d0 D kallsyms_addresses
     88182660 D kallsyms_num_syms
     88182670 D kallsyms_names
    -88190630 D kallsyms_markers
    -881906a0 D kallsyms_token_table
    -88190b50 D kallsyms_token_index
    +881906a0 D kallsyms_markers
    +88190710 D kallsyms_token_table
    +88190bc0 D kallsyms_token_index
     88191000 D irq_desc
     88191000 A __per_cpu_end
     88191000 A __per_cpu_start

    So for some reason we have a 0x70 variance between these, and only
    these. Running with --all-symbols this seems to work fine.

    Looking at scripts/kallsyms.c:symbol_valid, we see:

    /* Symbols which vary between passes. Passes 1 and 2 must have
     * identical symbol lists. The kallsyms_* symbols below are only added
     * after pass 1, they would be included in pass 2 when --all-symbols is
     * specified so exclude them to get a stable symbol list.
     */

    Going by this it's not entirely clear if there is a problem or not. If
    these symbols are supposed to be excluded due to being "special", then
    it doesn't seem like verify_kallsyms in the top-level Makefile is doing
    the right thing by just doing a blind cmp -s. This comment also seems to
    be a bit outdated or just generally inaccurate, as --all-symbols isn't
    the default behaviour unless CONFIG_KALLSYMS_ALL is set.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Linus Torvalds: "Re: ptrace single-stepping change breaks Wine"

    Relevant Pages

    • Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.48-00
      ... >> fix. ... addresses are not allowed to move between kallsyms passes, ... the working set hides this peculiarity, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.8-rc2-mm1
      ... Took a look at this and atm compiling a sparc tool-chain to try it out. ... because we do not do the kallsyms stuff if not configured in. ... rules in one place if sparc needs special rules. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] kallsyms C_SYMBOL_PREFIX support
      ... > kallsyms does not consider SYMBOL_PREFIX of C. ... Maybe even a bigger message, ... At least the patch seems to not affect architectures that don't use the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: "Needlessly global functions static...."
      ... On Dunnersdag 17 Februar 2005 22:25, Chris Wright wrote: ... > are in kallsyms or System.map. ... gcc -funit-at-a-time. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.7-mm6 - ppc32 inconsistent kallsyms data
      ... > I'm getting this while building for ppc32: ... >bug, and reads like kallsyms is a utility or part of the toolchain; ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)