/proc/kallsyms broken in 2.6.26-rc1-git6

/proc/kallsyms broken in 2.6.26-rc1-git6

[Andi Kleen]

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

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Paulo Marques]

Andi Kleen wrote:
> 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]

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"

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Andi Kleen]

>> ffffffff80337043 u idr_pre_get  [i2c_core]
>> ffffc2000007573e ? DW.sched.h.920090ff.56       [i2c_core]
> 
> Are you compiling with CONFIG_KALLSYMS_ALL?

Yep.

CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set

> If you are, kallsyms will store all the output of "nm -n vmlinux" no
> matter what section the symbol belongs to...

Yes and? Surely that's not correct?

-Andi

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Paulo Marques]

Andi Kleen wrote:
>>> ffffffff80337043 u idr_pre_get  [i2c_core]
>>> ffffc2000007573e ? DW.sched.h.920090ff.56       [i2c_core]
>> Are you compiling with CONFIG_KALLSYMS_ALL?
> 
> Yep.
> 
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> # CONFIG_KALLSYMS_EXTRA_PASS is not set
> 
>> If you are, kallsyms will store all the output of "nm -n vmlinux" no
>> matter what section the symbol belongs to...
> 
> Yes and? Surely that's not correct?

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."

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Andi Kleen]

> That's not for me to judge, but I believe it has always been like that.

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
make any sense because they don't have any valid kernel addresses.

> 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.

I noticed a change in behavior.

> 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.

Nothing particular. I uploaded the config at
http://halobates.de/basil-config

> 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.

It's the other way round -- kallsyms changed and that change will likely
break programs.

-Andi

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Paulo Marques]

Andi Kleen wrote:
>> That's not for me to judge, but I believe it has always been like that.
> 
> No, normally /proc/kallsyms looks similar to System.tap. Where are all
> these DW.* symbols coming from? 

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 
same symbols don't appear in System.map?

> They didn't use to be there and don't
> make any sense because they don't have any valid kernel addresses.

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 
that starts at offset 0.

>> 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.
> 
> I noticed a change in behavior.

Ok.

>> 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.
> 
> Nothing particular. I uploaded the config at
> http://halobates.de/basil-config

Well, my first suspects would be these:

CONFIG_KPROBES=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y

>> 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.
> 
> It's the other way round -- kallsyms changed and that change will likely
> break programs.

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."

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Andi Kleen]

> 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 
> same symbols don't appear in System.map?

They do, but that's also new.

> 
> >They didn't use to be there and don't
> >make any sense because they don't have any valid kernel addresses.
> 
> 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 
> that starts at offset 0.

I don't know too much about the markers implementation either and
if it's caused by then.

> Well, my first suspects would be these:
> 
> CONFIG_KPROBES=y
> CONFIG_KRETPROBES=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y

I've always had those enabled and afaik they don't generate any 
magic symbols.

> 
> >
> >It's the other way round -- kallsyms changed and that change will likely
> >break programs.
> 
> 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...

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

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Alexey Dobriyan]

On Fri, May 09, 2008 at 08:59:56PM +0100, Paulo Marques wrote:
> Andi Kleen wrote:
>>>> ffffffff80337043 u idr_pre_get  [i2c_core]
>>>> ffffc2000007573e ? DW.sched.h.920090ff.56       [i2c_core]
>>> Are you compiling with CONFIG_KALLSYMS_ALL?
>> Yep.
>> CONFIG_KALLSYMS=y
>> CONFIG_KALLSYMS_ALL=y
>> # CONFIG_KALLSYMS_EXTRA_PASS is not set
>>> If you are, kallsyms will store all the output of "nm -n vmlinux" no
>>> matter what section the symbol belongs to...
>> 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
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
	...

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Paulo Marques]

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

"God is love. Love is blind. Ray Charles is blind. Ray Charles is God."

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Cyrill Gorcunov]

[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).
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 -

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Sam Ravnborg]

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

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Cyrill Gorcunov]

[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 -

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Andi Kleen]

> 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.

-Andi

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Sam Ravnborg]

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 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
 

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Cyrill Gorcunov]

[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 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
|  
| 

Hi Sam,

should not there be

	toupper(stype) == 'N'

(just a guess)

		- Cyrill -

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Sam Ravnborg]

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
> | +++ 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
> |  
> | 
> 
> Hi Sam,
> 
> should not there be
> 
> 	toupper(stype) == 'N'
> 
> (just a guess)

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

Re: /proc/kallsyms broken in 2.6.26-rc1-git6

[Cyrill Gorcunov]

[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
| > | +++ 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
| > |  
| > | 
| > 
| > Hi Sam,
| > 
| > should not there be
| > 
| > 	toupper(stype) == 'N'
| > 
| > (just a guess)
| 
| 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
| 

ok, thanks

		- Cyrill -