Re: arm: Inconsistent kallsyms data

[Keith Owens <kaos@ocs.com.au>]

On Wed, 11 May 2005 12:05:10 +0300, 
Imre Deak <imre.deak@nokia.com> wrote:
>building 2.6.12-rc4 results in "Inconsistent kallsyms data". Setting
>CONFIG_KALLSYMS_EXTRA_PASS=y doesn't help.
>
>I made a diff of .tmp_kallsyms[12].S after converting them to human
>readable form with kallsyms_uncompress.pl .
>
>--- .tmp_kallsyms1.txt	2005-05-11 11:54:50.000000000 +0300
>+++ .tmp_kallsyms2.txt	2005-05-11 11:54:55.000000000 +0300
>@@ -16718,773 +16718,773 @@
> d gss_kerberos_pfs 	PTR	0xc02ae46c
> d gss_kerberos_ops 	PTR	0xc02ae494
> D net_table 	PTR	0xc02ae4a4
>-D _edata 	PTR	0xc02ae554
>-B __bss_start 	PTR	0xc02ae560
>-B system_state 	PTR	0xc02ae560
>.....
>+B __bss_start 	PTR	0xc02e8a00
>+D _edata 	PTR	0xc02e8a00
>+B system_state 	PTR	0xc02e8a00
>...

The problem is being caused by alignment padding combined with a sort
order combined with the token compression in scripts/kallsyms.c.

Pass 1 generates this map extract.  Note the gap between _edata and
__bss_start, this is linker generated padding to start .bss on a 16
byte boundary.

...
c02ae4a4 D net_table
c02ae554 D _edata
c02ae560 B __bss_start
c02ae560 B system_state
c02ae564 B saved_command_line

...

Pass 2 defines the kallsyms_* symbols and generates data for them.
That adds new symbols and increases _edata, all perfectly normal.

...
c02ae4a4 D net_table
c02ae560 D kallsyms_addresses
c02bf6b0 D kallsyms_num_syms
c02bf6c0 D kallsyms_names
c02e82b0 D kallsyms_markers
c02e83d0 D kallsyms_token_table
c02e8800 D kallsyms_token_index
c02e8a00 B __bss_start
c02e8a00 B system_state
c02e8a00 D _edata
c02e8a04 B saved_command_line
...

After adding the kallsyms data in pass 2, there is no longer a gap
between _edata and __bss_start.  The added kallsyms data moved _edata
to a 16 byte boundary which removed the need for the linker to add any
padding.

When $(NM) is run to produce the map, the -n option first sorts by
address, then by symbol type, then by name.  When two symbols like
_edata and __bss_start have the same address they sort by type.  D
comes after B which changes the order of the output symbols.  That in
turn changes the input to the token compression code in
scripts/kallsyms.c which finally results in different kallsyms output.

This problem can only affect the padding between _edata and the start
of the next section, and only when the amount of padding is zero in one
kallsyms pass and non-zero in another.  The simplest solution is to
change the vmlinux.lds files to add '. = . + 1;' between the definition
of _edata and the start of the next section.  That ensures that _edata
never has the same address as the start of the next section and the
problem goes away.  Of course it means changing 30 vmlinux.lds files,
but it is the same one line change in all of them.

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