1. 29 May, 2018 1 commit
  2. 17 May, 2018 1 commit
  3. 06 Mar, 2018 1 commit
    • Ard Biesheuvel's avatar
      scripts/kallsyms: filter arm64's __efistub_ symbols · 1212f7a1
      Ard Biesheuvel authored
      On arm64, the EFI stub and the kernel proper are essentially the same
      binary, although the EFI stub executes at a different virtual address
      as the kernel. For this reason, the EFI stub is restricted in the
      symbols it can link to, which is ensured by prefixing all EFI stub
      symbols with __efistub_ (and emitting __efistub_ prefixed aliases for
      routines that may be shared between the core kernel and the stub)
      These symbols are leaking into kallsyms, polluting the namespace, so
      let's filter them explicitly.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  4. 02 Mar, 2018 1 commit
  5. 13 Oct, 2017 1 commit
    • Guenter Roeck's avatar
      scripts/kallsyms.c: ignore symbol type 'n' · 51962a9d
      Guenter Roeck authored
      gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
      '-frecord-gcc-switches'.  In most cases, those symbols are reported with
      nm as
      	000000000000000e n $d
      and with objdump as
      	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
      	000000000000000e l       .GCC.command.line	0000000000000000 $d
      Those symbols are detected in is_arm_mapping_symbol() and ignored.
      However, if "--prefix-symbols=<prefix>" is configured as well, the
      situation is different.  For example, in efi/libstub, arm64 images are
      built with
      	'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
      In combination with '-frecord-gcc-switches', the symbols are now reported
      by nm as:
      	000000000000000e n __efistub_$d
      and by objdump as:
      	0000000000000000 l    d  .GCC.command.line	0000000000000000 .GCC.command.line
      	000000000000000e l       .GCC.command.line	0000000000000000 __efistub_$d
      Those symbols are no longer ignored and included in the base address
      calculation.  This results in a base address of 000000000000000e, which
      in turn causes kallsyms to abort with
          kallsyms failure:
      	relative symbol value 0xffffff900800a000 out of range in relative mode
      The problem is seen in little endian arm64 builds with CONFIG_EFI
      enabled and with '-frecord-gcc-switches' set in KCFLAGS.
      Explicitly ignore symbols of type 'n' since those are clearly debug
      Link: http://lkml.kernel.org/r/1507136063-3139-1-git-send-email-linux@roeck-us.netSigned-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  6. 03 Feb, 2017 1 commit
    • Ard Biesheuvel's avatar
      kbuild: modversions: add infrastructure for emitting relative CRCs · 56067812
      Ard Biesheuvel authored
      This add the kbuild infrastructure that will allow architectures to emit
      vmlinux symbol CRCs as 32-bit offsets to another location in the kernel
      where the actual value is stored. This works around problems with CRCs
      being mistaken for relocatable symbols on kernels that self relocate at
      runtime (i.e., powerpc with CONFIG_RELOCATABLE=y)
      For the kbuild side of things, this comes down to the following:
       - introducing a Kconfig symbol MODULE_REL_CRCS
       - adding a -R switch to genksyms to instruct it to emit the CRC symbols
         as references into the .rodata section
       - making modpost distinguish such references from absolute CRC symbols
         by the section index (SHN_ABS)
       - making kallsyms disregard non-absolute symbols with a __crc_ prefix
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 11 Dec, 2016 1 commit
  8. 07 Apr, 2016 2 commits
  9. 15 Mar, 2016 2 commits
    • Ard Biesheuvel's avatar
      kallsyms: add support for relative offsets in kallsyms address table · 2213e9a6
      Ard Biesheuvel authored
      Similar to how relative extables are implemented, it is possible to emit
      the kallsyms table in such a way that it contains offsets relative to
      some anchor point in the kernel image rather than absolute addresses.
      On 64-bit architectures, it cuts the size of the kallsyms address table
      in half, since offsets between kernel symbols can typically be expressed
      in 32 bits.  This saves several hundreds of kilobytes of permanent
      .rodata on average.  In addition, the kallsyms address table is no
      longer subject to dynamic relocation when CONFIG_RELOCATABLE is in
      effect, so the relocation work done after decompression now doesn't have
      to do relocation updates for all these values.  This saves up to 24
      bytes (i.e., the size of a ELF64 RELA relocation table entry) per value,
      which easily adds up to a couple of megabytes of uncompressed __init
      data on ppc64 or arm64.  Even if these relocation entries typically
      compress well, the combined size reduction of 2.8 MB uncompressed for a
      ppc64_defconfig build (of which 2.4 MB is __init data) results in a ~500
      KB space saving in the compressed image.
      Since it is useful for some architectures (like x86) to retain the
      ability to emit absolute values as well, this patch also adds support
      for capturing both absolute and relative values when
      KALLSYMS_ABSOLUTE_PERCPU is in effect, by emitting absolute per-cpu
      addresses as positive 32-bit values, and addresses relative to the
      lowest encountered relative symbol as negative values, which are
      subtracted from the runtime address of this base symbol to produce the
      actual address.
      Support for the above is enabled by default for all architectures except
      IA-64 and Tile-GX, whose symbols are too far apart to capture in this
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Ard Biesheuvel's avatar
      kallsyms: don't overload absolute symbol type for percpu symbols · 8c996940
      Ard Biesheuvel authored
      Commit c6bda7c9 ("kallsyms: fix percpu vars on x86-64 with
      relocation") overloaded the 'A' (absolute) symbol type to signify that a
      symbol is not subject to dynamic relocation.  However, the original A
      type does not imply that at all, and depending on the version of the
      toolchain, many A type symbols are emitted that are in fact relative to
      the kernel text, i.e., if the kernel is relocated at runtime, these
      symbols should be updated as well.
      For instance, on sparc32, the following symbols are emitted as absolute
      (kindly provided by Guenter Roeck):
        f035a420 A _etext
        f03d9000 A _sdata
        f03de8c4 A jiffies
        f03f8860 A _edata
        f03fc000 A __init_begin
        f041bdc8 A __init_text_end
        f0423000 A __bss_start
        f0423000 A __init_end
        f044457d A __bss_stop
        f044457d A _end
      On x86_64, similar behavior can be observed:
        ffffffff81a00000 A __end_rodata_hpage_align
        ffffffff81b19000 A __vvar_page
        ffffffff81d3d000 A _end
      Even if only a couple of them pass the symbol range check that results
      in them to be taken into account for the final kallsyms symbol table, it
      is obvious that 'A' does not mean the symbol does not need to be updated
      at relocation time, and overloading its meaning to signify that is
      perhaps not a good idea.
      So instead, add a new percpu_absolute member to struct sym_entry, and
      when --absolute-percpu is in effect, use it to record symbols whose
      addresses should be emitted as final values rather than values that
      still require relocation at runtime.  That way, we can drop the check
      against the 'A' type.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 07 Apr, 2015 2 commits
    • Ard Biesheuvel's avatar
      Kbuild: kallsyms: drop special handling of pre-3.0 GCC symbols · 41b585b2
      Ard Biesheuvel authored
      Since we have required at least GCC v3.2 for some time now, we
      can drop the special handling of the 'gcc[0-9]_compiled.' label
      which is not emitted anymore since GCC v3.0.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
    • Ard Biesheuvel's avatar
      Kbuild: kallsyms: ignore veneers emitted by the ARM linker · bd8b22d2
      Ard Biesheuvel authored
      When linking large kernels on ARM, the linker will insert veneers
      (i.e., PLT like stubs) when function symbols are out of reach for
      the ordinary relative branch/branch-and-link instructions.
      However, due to the fact that the kallsyms region sits in .rodata,
      which is between .text and .init.text, additional veneers may be
      emitted in the second pass due to the fact that the size of the
      kallsyms region itself has pushed the .init.text section further
      apart, requiring even more veneers.
      So ignore the veneers when generating the symbol table. Veneers
      have no corresponding source code, and they will not turn up in
      backtraces anyway.
      This patch also lightly refactors the symbol_valid() function
      to use a local 'sym_name' rather than the obfuscated 'sym + 1'
      and 'sym + offset'
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  11. 02 Oct, 2014 1 commit
    • Kyle McMartin's avatar
      aarch64: filter $x from kallsyms · 6c34f1f5
      Kyle McMartin authored
      Similar to ARM, AArch64 is generating $x and $d syms... which isn't
      terribly helpful when looking at %pF output and the like. Filter those
      out in kallsyms, modpost and when looking at module symbols.
      Seems simplest since none of these check EM_ARM anyway, to just add it
      to the strchr used, rather than trying to make things overly
      initcall_debug improves:
      dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
      dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs
      Signed-off-by: default avatarKyle McMartin <kyle@redhat.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  12. 10 Jun, 2014 1 commit
  13. 17 Mar, 2014 2 commits
    • Rusty Russell's avatar
      kallsyms: fix percpu vars on x86-64 with relocation. · c6bda7c9
      Rusty Russell authored
      x86-64 has a problem: per-cpu variables are actually represented by
      their absolute offsets within the per-cpu area, but the symbols are
      not emitted as absolute.  Thus kallsyms naively creates them as offsets
      from _text, meaning their values change if the kernel is relocated
      (especially noticeable with CONFIG_RANDOMIZE_BASE):
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.nokaslr
       0000000000000000 D __per_cpu_start
       0000000000004000 D gdt_page
       0000000000014280 D __per_cpu_end
       ffffffff810001c8 T _stext
       ffffffff81ee53c0 D __per_cpu_offset
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.kaslr1
       000000001f200000 D __per_cpu_start
       000000001f204000 D gdt_page
       000000001f214280 D __per_cpu_end
       ffffffffa02001c8 T _stext
       ffffffffa10e53c0 D __per_cpu_offset
      Making them absolute symbols is the Right Thing, but requires fixes to
      the relocs tool.  So for the moment, we add a --absolute-percpu option
      which makes them absolute from a kallsyms perspective:
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # no KASLR
       0000000000000000 A __per_cpu_start
       000000000000a000 A gdt_page
       0000000000013040 A __per_cpu_end
       ffffffff802001c8 T _stext
       ffffffff8099b180 D __per_cpu_offset
       ffffffff809a3000 D __per_cpu_load
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # With KASLR
       0000000000000000 A __per_cpu_start
       000000000000a000 A gdt_page
       0000000000013040 A __per_cpu_end
       ffffffff89c001c8 T _stext
       ffffffff8a39d180 D __per_cpu_offset
       ffffffff8a3a5000 D __per_cpu_load
      Based-on-the-original-screenplay-by: default avatarAndy Honig <ahonig@google.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
    • Kees Cook's avatar
      kallsyms: generalize address range checking · 78eb7159
      Kees Cook authored
      This refactors the address range checks to be generalized instead of
      specific to text range checks, in preparation for other range checks.
      Also extracts logic for "is the symbol absolute" into a function.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  14. 11 Mar, 2014 1 commit
  15. 04 Mar, 2014 1 commit
    • Andy Honig's avatar
      kallsyms: fix absolute addresses for kASLR · 0f55159d
      Andy Honig authored
      Currently symbols that are absolute addresses are incorrectly displayed
      in /proc/kallsyms if the kernel is loaded with kASLR.
      The problem was that the scripts/kallsyms.c file which generates the
      array of symbol names and addresses uses an relocatable value for all
      symbols, even absolute symbols.  This patch fixes that.
      Several kallsyms output in different boot states for comparison:
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.nokaslr
        0000000000000000 D __per_cpu_start
        0000000000014280 D __per_cpu_end
        ffffffff810001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr1
        000000001f200000 D __per_cpu_start
        000000001f214280 D __per_cpu_end
        ffffffffa02001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr2
        000000000d400000 D __per_cpu_start
        000000000d414280 D __per_cpu_end
        ffffffff8e4001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr-fixed
        0000000000000000 D __per_cpu_start
        0000000000014280 D __per_cpu_end
        ffffffffadc001c8 T _stext
      Signed-off-by: default avatarAndy Honig <ahonig@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 13 Nov, 2013 1 commit
  17. 08 Nov, 2013 1 commit
  18. 06 Nov, 2013 1 commit
  19. 01 Nov, 2013 1 commit
    • Ming Lei's avatar
      scripts/kallsyms: filter symbols not in kernel address space · f6537f2f
      Ming Lei authored
      This patch uses CONFIG_PAGE_OFFSET to filter symbols which
      are not in kernel address space because these symbols are
      generally for generating code purpose and can't be run at
      kernel mode, so we needn't keep them in /proc/kallsyms.
      For example, on ARM there are some symbols which may be
      linked in relocatable code section, then perf can't parse
      symbols any more from /proc/kallsyms, this patch fixes the
      problem (introduced b9b32bf7)
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@vger.kernel.org
  20. 12 May, 2011 1 commit
    • Xiaochen Wang's avatar
      scripts/kallsyms.c: fix potential segfault · e0a04b11
      Xiaochen Wang authored
      This bug hardly appears during real kernel compiling,
       because the vmlinux symbols table is huge.
      But we can still catch it under strict condition , as follows.
         $ echo "c101b97b T do_fork" | ./scripts/kallsyms --all-symbols
         #include <asm/types.h>
         .globl kallsyms_token_table
         Segmentation fault (core dumped)
      If symbols table is small, all entries in token_profit[0x10000] may
      decrease to 0 after several calls of compress_symbols() in optimize_result().
      In that case, find_best_token() always return 0 and
      best_table[i] is set to "\0\0" and best_table_len[i] is set to 2.
      As a result, expand_symbol(best_table[0]="\0\0", best_table_len[0]=2, buf)
      in write_src() will run in infinite recursion until stack overflows,
      causing segfault.
      This patch checks the find_best_token() return value. If all entries in
      token_profit[0x10000] become 0 according to return value, it breaks the loop
      in optimize_result().
      And expand_symbol() works well when best_table_len[i] is 0.
      Signed-off-by: default avatarXiaochen Wang <wangxiaochen0@gmail.com>
      Acked-by: default avatarPaulo Marques <pmarques@grupopie.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  21. 29 Sep, 2010 1 commit
  22. 02 Feb, 2010 1 commit
  23. 23 Sep, 2009 1 commit
    • Paul Mundt's avatar
      kallsyms: fix segfault in prefix_underscores_count() · a9ece53c
      Paul Mundt authored
      Commit b478b782 "kallsyms, tracing: output
      more proper symbol name" introduces a "bugfix" that introduces a segfault
      in kallsyms in my configurations.
      The cause is the introduction of prefix_underscores_count() which attempts
      to count underscores, even in symbols that do not have them.  As a result,
      it just uselessly runs past the end of the buffer until it crashes:
        CC      init/version.o
        LD      init/built-in.o
        LD      .tmp_vmlinux1
        KSYM    .tmp_kallsyms1.S
      /bin/sh: line 1: 16934 Done                    sh-linux-gnu-nm -n .tmp_vmlinux1
           16935 Segmentation fault      | scripts/kallsyms > .tmp_kallsyms1.S
      make: *** [.tmp_kallsyms1.S] Error 139
      This simplifies the logic and just does a straightforward count.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Reviewed-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>		[2.6.30.x, 2.6.31.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  24. 20 Jun, 2009 1 commit
  25. 14 Jun, 2009 2 commits
  26. 14 Mar, 2009 1 commit
    • Lai Jiangshan's avatar
      kallsyms, tracing: output more proper symbol name · b478b782
      Lai Jiangshan authored
      Impact: bugfix, output more reliable symbol lookup result
      Debug tools(dump_stack(), ftrace...) are like to print out symbols.
      But it is always print out the first aliased symbol.(Aliased symbols
      are symbols with the same address), and the first aliased symbol is
      sometime not proper.
       # echo function_graph > current_tracer
       # cat trace
       1)   1.923 us    |    select_nohz_load_balancer();
       1) + 76.692 us   |  }
       1)               |  default_idle() {
       1)   ==========> |    __irqentry_text_start() {
       1)   0.000 us    |      native_apic_mem_write();
       1)               |      irq_enter() {
       1)   0.000 us    |        idle_cpu();
       1)               |        tick_check_idle() {
       1)   0.000 us    |          tick_check_oneshot_broadcast();
       1)               |          tick_nohz_stop_idle() {
      It's very embarrassing, it ouputs "__irqentry_text_start()",
      actually, it should output "smp_apic_timer_interrupt()".
      (these two symbol are the same address, but "__irqentry_text_start"
      is deemed to the first aliased symbol by scripts/kallsyms)
      This patch puts symbols like "__irqentry_text_start" to the second
      aliased symbols. And a more proper symbol name becomes the first.
      Aliased symbols mostly come from linker script. The solution is
      guessing "is this symbol defined in linker script", the symbols
      defined in linker script will not become the first aliased symbol.
      And if symbols are found to be equal in this "linker script provided"
      criteria, symbols are sorted by the number of prefix underscores.
      Signed-off-by: Lai Jiangshan's avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Reviewed-by: default avatarPaulo Marques <pmarques@grupopie.com>
      LKML-Reference: <49BA06E2.7080807@cn.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  27. 14 Jan, 2009 1 commit
  28. 19 Dec, 2008 1 commit
    • Jan Beulich's avatar
      allow stripping of generated symbols under CONFIG_KALLSYMS_ALL · 9bb48247
      Jan Beulich authored
      Building upon parts of the module stripping patch, this patch
      introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y.
      Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of
      CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64)
      kernels I tested with.
      The patch also does away with the need to special case the kallsyms-
      internal symbols by making them available even in the first linking
      While it is a generated file, the patch includes the changes to
      scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure
      here is.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  29. 19 May, 2008 1 commit
    • Sam Ravnborg's avatar
      kbuild: filter away debug symbols from kernel symbols · aab34ac8
      Sam Ravnborg authored
      Andi Kleen <andi@firstfloor.org>
      reported that he saw a lot of symbols like this:
      0000000000000b24 N DW.aio.h.903a6d92.2
      0000000000000bce N DW.task_io_accounting.h.8d8de327.0
      0000000000000bec N DW.hrtimer.h.c23659c6.0
      in his System.map / kallsyms output.
      Simple solution is to skip all debugging
      symbols (they are marked 'N').
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Paulo Marques <pmarques@grupopie.com>
  30. 30 Apr, 2008 1 commit
  31. 06 Feb, 2008 2 commits
  32. 17 Jul, 2007 2 commits
  33. 08 Dec, 2006 1 commit