sh: inconsistent kallsyms data

sh: inconsistent kallsyms data

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: sh: inconsistent kallsyms data

[pmarques]

Quoting Paul Mundt <lethal@linux-sh.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.

I think the only change from 2.6.9 that could affect this is the addition of the
is_arm_mapping_symbol from Russel King.

Can you try to comment out this function in scripts/kallsyms.c (and the call to
it in read_symbol) and see if it changes the result for you?

--
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: sh: inconsistent kallsyms data

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

On Fri, Dec 31, 2004 at 05:59:31PM +0000, pmarques@grupopie.com wrote:
> I think the only change from 2.6.9 that could affect this is the
> addition of the is_arm_mapping_symbol from Russel King.
> 
This wouldn't make any difference as that only gets invoked by
read_symbol() for U type symbols, which is unrelated.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: sh: inconsistent kallsyms data

[pmarques]

Quoting Paul Mundt <lethal@linux-sh.org>:

> On Fri, Dec 31, 2004 at 05:59:31PM +0000, pmarques@grupopie.com wrote:
> > I think the only change from 2.6.9 that could affect this is the
> > addition of the is_arm_mapping_symbol from Russel King.
> > 
> This wouldn't make any difference as that only gets invoked by
> read_symbol() for U type symbols, which is unrelated.


You mis-read the 'if'. The symbol is not used it is of 'U' type *or*
is_arm_mapping_symbol. This means that is_arm_mapping_symbol will be called for
all the symbols that are not of type 'U'.

Anyway, Keith Owens might be right. I forgot that this change only went into the
official tree now, and was under the impression that was already in 2.6.9 :(

It seems from the symptoms that the kallsyms_names array was 0x70 bytes larger
on the second run. This shouldn't happen if the algorithm is ran over the same
symbols, not matter how complex the algorithm is.

I was the one who wrote the algorithm, so I'm probably in the best position to
debug it. If you send Keith the info he requested, send it to me too, so that I
have some more data to look at.

--
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu

Re: sh: inconsistent kallsyms data

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Fri, Dec 31, 2004 at 07:29:16PM +0000, pmarques@grupopie.com wrote:
> You mis-read the 'if'. The symbol is not used it is of 'U' type *or*
> is_arm_mapping_symbol. This means that is_arm_mapping_symbol will be
> called for all the symbols that are not of type 'U'.
> 
Yeah, I noticed that after I had modified the if and commented out the
is_arm_mapping_symbol and replied already. It made no difference
anyways.

> I was the one who wrote the algorithm, so I'm probably in the best
> position to debug it. If you send Keith the info he requested, send it
> to me too, so that I have some more data to look at.
> 
Keith already replied to this privately so I'll leave it at that. Let me
know if you need anything else.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: sh: inconsistent kallsyms data

[Keith Owens]

On Fri, 31 Dec 2004 19:25:50 +0200, 
Paul Mundt <lethal@linux-sh.org> wrote:
>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.

I suspect the change in the kallsyms compression algorithm between
2.6.9 and 2.6.10.  It added 3 new symbols and I am not convinced that
they are being processed correctly by scripts/kallsyms.c.  Apply this
debug patch, tar .tmp_kallsyms* and send the tarball to me.

Index: 2.6.10-pristine/Makefile
===================================================================
--- 2.6.10-pristine.orig/Makefile	2004-12-25 10:25:19.000000000 +1100
+++ 2.6.10-pristine/Makefile	2005-01-01 05:13:25.714459901 +1100
@@ -680,7 +680,7 @@ define verify_kallsyms
 	$(Q)cmp -s System.map .tmp_System.map ||              \
 		(echo Inconsistent kallsyms data;             \
 		 echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; \
-		 rm .tmp_kallsyms* ; /bin/false )
+		 /bin/false )
 endef
 
 # Update vmlinux version before link

Re: sh: inconsistent kallsyms data

[Keith Owens]

On Fri, 31 Dec 2004 19:25:50 +0200, 
Paul Mundt <lethal@linux-sh.org> wrote:
>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.

It is a nasty corner case in scripts/kallsyms.c processing.  There is a
difference in the list of names between pass 1 and pass 2.  This is not
supposed to happen, the name and compression tables must be the same
after pass 1 and 2.  The symbol addresses will be different, but the
amount of data must be the same.

--- out1        2005-01-01 14:30:30.192497864 +1100
+++ out2        2005-01-01 14:30:46.556974017 +1100
@@ -5854,390 +5854,389 @@
 r __param_yres         PTR     0x8816d300
 r __param_xres         PTR     0x8816d314
 A _etext       PTR     0x8816d328
-D init_task    PTR     0x8816d328
 R __stop___param       PTR     0x8816d328

In pass 1, init_task has the same value as _etext so it is included in
the name table.  Adding the kallsyms data to vmlinux at the end of pass
1 adds more data which shifts where init_task is linked so it is no
longer the same as _etext, so we lose a symbol on pass 2 which breaks
the kallsyms rules.

This corner case only occurs with CONFIG_KALLSYMS_ALL=n.  That is the
only time that we drop symbols outside the ranges _stext ... _etext and
_sinittext ... _einittext.  For CONFIG_KALLSYMS_ALL=n, we want the
_etext and _einittext labels, but not any other symbols that have the
same numeric value as _etext or _einittext.

Paul, please test this patch.  Build with CONFIG_KALLSYMS_ALL=n and
CONFIG_KALLSYMS_EXTRA_PASS=n.

Index: 2.6.10/scripts/kallsyms.c
===================================================================
--- 2.6.10.orig/scripts/kallsyms.c	2005-01-01 14:24:21.240400295 +1100
+++ 2.6.10/scripts/kallsyms.c	2005-01-01 14:54:57.695169107 +1100
@@ -184,6 +184,16 @@ symbol_valid(struct sym_entry *s)
 		if ((s->addr < _stext || s->addr > _etext)
 		    && (s->addr < _sinittext || s->addr > _einittext))
 			return 0;
+		/* Corner case.  Discard any symbols with the same value as
+		 * _etext or _einittext, they can move between pass 1 and 2
+		 * when the kallsyms data is added.  If these symbols move then
+		 * they may get dropped in pass 2, which breaks the kallsyms
+		 * rules.
+		 */
+		if ((s->addr == _etext || s->addr == _einittext) &&
+		    strcmp(s->sym + 1, "_etext") &&
+		    strcmp(s->sym + 1, "_einittext"))
+			return 0;
 	}
 
 	/* Exclude symbols which vary between passes. */


BTW, this script will take a .tmp_kallsyms<n>.S file and convert the
tables to something that a human can read.

#!/usr/bin/perl -w
#
# kallsyms_uncompress.pl (C) Keith Owens 2005 <kaos@ocs.com.au>
#
# Released under GPL V2.
#
# Uncompress the names in a .tmp_kallsymsn.S file.  Humans need text strings
# to work out why kallsyms is giving inconsistent results.  Use on 2.6.10
# onwards.
# kallsyms_uncompress.pl .tmp_kallsymsn.S > outfile

use strict;
die($0 . " takes exactly one argument\n") if($#ARGV != 0);

my @token;
my @name;
my @ptr;

my $line;
my $state = 0;	# 1 token, 2 name, 3 ptr

while (defined ($line = <>)) {
	chomp($line);
	if ($line eq "kallsyms_token_table:") {
		$state = 1;
		next;
	}
	if ($line eq "kallsyms_names:") {
		$state = 2;
		next;
	}
	if ($line eq "kallsyms_addresses:") {
		$state = 3;
		next;
	}
	next if ($state == 0);
	if ($line eq "") {
		$state = 0;
		next;
	}
	if ($state == 1) {
		$line =~ s/[^"]*"//;
		$line =~ s/"//;
		push(@token, $line);
	} elsif ($state == 2) {
		$line =~ s/\s//g;
		my @b = (split(/,/, $line));
		shift(@b);
		push(@name, \@b);
	} else {
		push(@ptr, $line);
	}
}

my ($b, $i, $text);
for ($i = 0; $i <= $#name; ++$i) {
	$text = "";
	foreach $b (@{$name[$i]}) {
		$text .= $token[hex($b)];
	}
	printf("%s %s %s\n", substr($text, 0, 1), substr($text, 1), $ptr[$i]);
}

Re: sh: inconsistent kallsyms data

[Keith Owens]

On Sat, 01 Jan 2005 14:59:19 +1100, 
Keith Owens <kaos@ocs.com.au> wrote:
>Paul, please test this patch.  Build with CONFIG_KALLSYMS_ALL=n and
>CONFIG_KALLSYMS_EXTRA_PASS=n.

ps.  Due to bugs in the kernel build system, you cannot assume that
changing scripts/kallsyms.c or CONFIG_KALLSYMS_ALL or
CONFIG_KALLSYMS_EXTRA_PASS will be automatically detected.  The make
dependency tree for the kallsyms code is incomplete.

After applying the patch and adjusting the config, touch init/main.c
then make.  Touching a file will force a kernel relink and work around
the incomplete dependency data.

Re: sh: inconsistent kallsyms data

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Sat, Jan 01, 2005 at 02:59:19PM +1100, Keith Owens wrote:
> This corner case only occurs with CONFIG_KALLSYMS_ALL=n.  That is the
> only time that we drop symbols outside the ranges _stext ... _etext and
> _sinittext ... _einittext.  For CONFIG_KALLSYMS_ALL=n, we want the
> _etext and _einittext labels, but not any other symbols that have the
> same numeric value as _etext or _einittext.
> 
> Paul, please test this patch.  Build with CONFIG_KALLSYMS_ALL=n and
> CONFIG_KALLSYMS_EXTRA_PASS=n.
> 
Works fine for me, thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]