login
Search
Haven't investigated why yet, but this doesn't seem right: # cat /proc/kallsyms 0000000000000b0c N DW.aio.h.903a6d92.0 0000000000000b19 N DW.aio.h.903a6d92.1 0000000000000b24 N DW.aio.h.903a6d92.2 0000000000000bce N DW.task_io_accounting.h.8d8de327.0 0000000000000bec N DW.hrtimer.h.c23659c6.0 0000000000000bf5 N DW.hrtimer.h.c23659c6.1 0000000000000c00 N DW.hrtimer.h.c23659c6.2 0000000000000c06 N DW.hrtimer.h.c23659c6.3 0000000000000c28 N DW.hrtimer.h.c23659c6.4 0000000000000c2e N DW.hrtimer.h.c23659c6.5 ... ffffffff80337043 u idr_pre_get [i2c_core] ffffc2000007573e ? DW.sched.h.920090ff.56 [i2c_core] -Andi --
Are you compiling with CONFIG_KALLSYMS_ALL? If you are, kallsyms will store all the output of "nm -n vmlinux" no matter what section the symbol belongs to... -- Paulo Marques - www.grupopie.com "C++ : increment the value of C and use the old one" --
Yep. CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y Yes and? Surely that's not correct? -Andi --
That's not for me to judge, but I believe it has always been like that. I just wanted to understand if you noticed a change in behavior (which is probably a bug) or if it has always been like that but you just noticed how ugly it is. Maybe you also have some debug or markers configuration or something that is generating extra symbols to a special section that is just making the problem look worse now. Anyway, I can change the way kallsyms works, but that has to be done with some care because there are some userspace tools that read /proc/kallsyms and we don't want to break those. A proper testing period through -mm should take care of that, though. -- Paulo Marques - www.grupopie.com "All generalizations are false." --
*cough* Here is how typical /proc/kallsyms looks like: ffffffff80200000 A _text ffffffff80200000 T startup_64 ffffffff802000b7 t ident_complete ffffffff80200100 T secondary_startup_64 ffffffff802001a0 T init_rsp ffffffff802001a8 t bad_address ffffffff80201000 T init_level4_pgt ffffffff80202000 T level3_ident_pgt ffffffff80203000 T level3_kernel_pgt ffffffff80204000 T level2_fixmap_pgt ffffffff80205000 T level1_fixmap_pgt ffffffff80206000 T level2_ident_pgt ffffffff80207000 T level2_kernel_pgt ffffffff80208000 T level2_spare_pgt ffffffff80209000 T _stext ffffffff80209000 t run_init_process ffffffff80209020 t init_post ffffffff80209120 T name_to_dev_t ffffffff802092a0 t hard_disable_TSC ffffffff802092b0 t hard_enable_TSC ffffffff802092c0 T arch_randomize_brk ffffffff80209300 T arch_align_stack ffffffff80209350 T do_arch_prctl ffffffff80209760 T disable_TSC ffffffff802097c0 T set_tsc_mode ffffffff80209830 T sys_vfork ffffffff80209860 T sys_clone ffffffff80209890 T sys_fork ffffffff802098c0 T sys_execve ffffffff80209940 T release_thread ffffffff80209980 T __show_regs ffffffff80209bc0 T show_regs ffffffff80209c10 t __exit_idle ffffffff80209c40 T enter_idle ffffffff80209c70 T idle_notifier_register ffffffff80209c90 T exit_idle ffffffff80209cc0 T set_personality_64bit ffffffff80209cf0 T get_wchan ffffffff80209da0 T sys_arch_prctl ffffffff80209dc0 T __switch_to ffffffff8020a140 T cpu_idle ffffffff8020a1f0 T start_thread ffffffff8020a290 T get_tsc_mode ffffffff8020a2c0 T prepare_to_copy ffffffff8020a320 T default_idle ffffffff8020a370 T flush_thread ffffffff8020a460 T exit_thread ffffffff8020a520 T copy_thread ffffffff8020a6e0 t get_stack ffffffff8020a740 t current_syscall ... --
This isn't helpful... the question is whether it is kallsyms misbehaving and placing new symbols in the kernel image or if it is some other change in the kernel that is generating new symbols that end up in the symbol table. My guess it is that it is the later, and in that case, from a kallsyms standpoint "it has always been like that". -- Paulo Marques - www.grupopie.com "God is love. Love is blind. Ray Charles is blind. Ray Charles is God." --
If it help - I've taken Andi's config, compiled the kernel and
didn't find any screwed symbols (nor is System.map nor in /proc/kallsyms).
The kernel - today Linus's git tree:
---
commit 492c2e476eac010962850006c49df326919b284c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun May 11 17:09:41 2008 -0700
Linux 2.6.26-rc2
---
The diff btw Andi's config and new one is:
+CONFIG_PCSPKR_PLATFORM=y
-CONFIG_PCNET32_NAPI=y
- Cyrill -
--
I expect it to be a toolchain issue. Andi is often running with gcc versions that are very new (fresh from svn maybe). I dunno about binutils. To reproduce I would expect that a very recent gcc/binutils is needed. Andi? Sam --
[Sam Ravnborg - Mon, May 12, 2008 at 07:23:23PM +0200] | On Mon, May 12, 2008 at 07:50:52PM +0400, Cyrill Gorcunov wrote: | > [Paulo Marques - Mon, May 12, 2008 at 11:00:32AM +0100] | > > Alexey Dobriyan wrote: | > >> On Fri, May 09, 2008 at 08:59:56PM +0100, Paulo Marques wrote: | > >>> Andi Kleen wrote: | > >>>> [...] | > >>>> Yes and? Surely that's not correct? | > >>> That's not for me to judge, but I believe it has always been like that. | > >> *cough* | > >> Here is how typical /proc/kallsyms looks like: | > >> ffffffff80200000 A _text | > >> ffffffff80200000 T startup_64 | > >> ffffffff802000b7 t ident_complete | > >> ffffffff80200100 T secondary_startup_64 | > > | > > This isn't helpful... the question is whether it is kallsyms misbehaving | > > and placing new symbols in the kernel image or if it is some other change | > > in the kernel that is generating new symbols that end up in the symbol | > > table. | > > | > > My guess it is that it is the later, and in that case, from a kallsyms | > > standpoint "it has always been like that". | > > | > > -- | > > Paulo Marques - www.grupopie.com | > > | > > | > | > If it help - I've taken Andi's config, compiled the kernel and | > didn't find any screwed symbols (nor is System.map nor in /proc/kallsyms). | | I expect it to be a toolchain issue. Andi is often running with gcc versions | that are very new (fresh from svn maybe). I dunno about binutils. | To reproduce I would expect that a very recent gcc/binutils is needed. | Andi? | | Sam | Probably, I've used: gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2) sys-devel/binutils 2.18-r1 - Cyrill - --
No actually that's a pretty old version from SUSE 10.2 gcc-4.1.3-29 binutils-2.17.50.0.5-21 This means i've been recently trying to get the x86-64 kernel to work with the new gold linker from binutils mainline, but it's far from Just a SUSE 10.2 toolchain. You can probably rpm2cpio it from any SUSE mirror. -Andi --
I have just commit the following that should fix it.
Sam
commit aab34ac8582303ef57b792710fc5dd5991477475
Author: Sam Ravnborg <sam@ravnborg.org>
Date: Mon May 19 20:07:58 2008 +0200
kbuild: filter away debug symbols from kernel symbols
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: Sam Ravnborg <sam@ravnborg.org>
Cc: Paulo Marques <pmarques@grupopie.com>
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 5d20a2e..ad2434b 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -108,6 +108,9 @@ static int read_symbol(FILE *in, struct sym_entry *s)
/* exclude also MIPS ELF local symbols ($L123 instead of .L123) */
else if (str[0] == '$')
return -1;
+ /* exclude debugging symbols */
+ else if (stype == 'N')
+ return -1;
/* include the type field in the symbol name, so that it gets
* compressed together */
diff --git a/scripts/mksysmap b/scripts/mksysmap
index 4390fab..6e133a0 100644
--- a/scripts/mksysmap
+++ b/scripts/mksysmap
@@ -32,6 +32,7 @@
# For System.map filter away:
# a - local absolute symbols
# U - undefined global symbols
+# N - debugging symbols
# w - local weak symbols
# readprofile starts reading symbols when _stext is found, and
@@ -40,5 +41,5 @@
# so we just ignore them to let readprofile continue to work.
# (At least sparc64 has __crc_ in the middle).
-$NM -n $1 | grep -v '\( [aUw] \)\|\(__crc_\)\|\( \$[adt]\)' > $2
+$NM -n $1 | grep -v '\( [aNUw] \)\|\(__crc_\)\|\( \$[adt]\)' > $2
--
[Sam Ravnborg - Mon, May 19, 2008 at 08:11:18PM +0200] | On Tue, May 13, 2008 at 11:54:37AM +0200, Andi Kleen wrote: | > > I expect it to be a toolchain issue. Andi is often running with gcc versions | > > that are very new (fresh from svn maybe). I dunno about binutils. | > | > No actually that's a pretty old version from SUSE 10.2 | > | > gcc-4.1.3-29 | > binutils-2.17.50.0.5-21 | > | > This means i've been recently trying to get the x86-64 kernel to work | > with the new gold linker from binutils mainline, but it's far from | > booting yet and was not used here. | > | > > To reproduce I would expect that a very recent gcc/binutils is needed. | > > Andi? | > | > Just a SUSE 10.2 toolchain. You can probably rpm2cpio it from any | > SUSE mirror. | | I have just commit the following that should fix it. | | Sam | | commit aab34ac8582303ef57b792710fc5dd5991477475 | Author: Sam Ravnborg <sam@ravnborg.org> | Date: Mon May 19 20:07:58 2008 +0200 | | kbuild: filter away debug symbols from kernel symbols | | 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: Sam Ravnborg <sam@ravnborg.org> | Cc: Paulo Marques <pmarques@grupopie.com> | | diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c | index 5d20a2e..ad2434b 100644 | --- a/scripts/kallsyms.c | +++ b/scripts/kallsyms.c | @@ -108,6 +108,9 @@ static int read_symbol(FILE *in, struct sym_entry *s) | /* exclude also MIPS ELF local symbols ($L123 instead of .L123) */ | else if (str[0] == '$') | return -1; | + /* exclude debugging symbols */ | + else if (stype == 'N') | + return -1; | | /* include the type field ...
I conisered this. But decided that we could do so if we needed it later. In the nm output I got they were all 'N'. Sam --
[Sam Ravnborg - Mon, May 19, 2008 at 08:21:15PM +0200] | On Mon, May 19, 2008 at 10:15:43PM +0400, Cyrill Gorcunov wrote: | > [Sam Ravnborg - Mon, May 19, 2008 at 08:11:18PM +0200] | > | On Tue, May 13, 2008 at 11:54:37AM +0200, Andi Kleen wrote: | > | > > I expect it to be a toolchain issue. Andi is often running with gcc versions | > | > > that are very new (fresh from svn maybe). I dunno about binutils. | > | > | > | > No actually that's a pretty old version from SUSE 10.2 | > | > | > | > gcc-4.1.3-29 | > | > binutils-2.17.50.0.5-21 | > | > | > | > This means i've been recently trying to get the x86-64 kernel to work | > | > with the new gold linker from binutils mainline, but it's far from | > | > booting yet and was not used here. | > | > | > | > > To reproduce I would expect that a very recent gcc/binutils is needed. | > | > > Andi? | > | > | > | > Just a SUSE 10.2 toolchain. You can probably rpm2cpio it from any | > | > SUSE mirror. | > | | > | I have just commit the following that should fix it. | > | | > | Sam | > | | > | commit aab34ac8582303ef57b792710fc5dd5991477475 | > | Author: Sam Ravnborg <sam@ravnborg.org> | > | Date: Mon May 19 20:07:58 2008 +0200 | > | | > | kbuild: filter away debug symbols from kernel symbols | > | | > | 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: Sam Ravnborg <sam@ravnborg.org> | > | Cc: Paulo Marques <pmarques@grupopie.com> | > | | > | diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c | > | index 5d20a2e..ad2434b 100644 | > | --- a/scripts/kallsyms.c | > | +++ ...
No, normally /proc/kallsyms looks similar to System.tap. Where are all these DW.* symbols coming from? They didn't use to be there and don't Nothing particular. I uploaded the config at It's the other way round -- kallsyms changed and that change will likely break programs. -Andi --
Hum... System.map is generated by running nm -n vmlinux | grep -v '\( [aUw] \)\|\(__crc_\)\|\( \$[adt]\)' > System.map whereas the kallsyms symbols come from: nm -n vmlinux So, the only difference is the filter made by that "grep -v" to exclude a few classes of symbols. Maybe I lost myself in that expression, but it doesn't seem like it would be able to filter out the symbols you're seeing. Are you sure the I don't know enough about the markers infrastructure but I guess these "addresses" are more like an "offset" into a markers structure that is automatically produced by putting these symbols into a special section Well, my first suspects would be these: CONFIG_KPROBES=y CONFIG_KRETPROBES=y CONFIG_HAVE_KPROBES=y I don't have the time right now to try your configuration and pinpoint the problem, but if you can come up with a plan, like: "we need to filter out symbols from the output of "nm" whose type is 'N'", I'll be more than happy to provide a patch to fix it... -- Paulo Marques - www.grupopie.com "Nostalgia isn't what it used to be." --
I don't know too much about the markers implementation either and I've always had those enabled and afaik they don't generate any man nm says "N" The symbol is a debugging symbol. while I'm not 100% sure what a debugging symbol is I suppose we don't need those so yes please filter those out (both out of System.map and out of kallsyms) -Andi --
