RE: arm: Inconsistent kallsyms data

[<Imre.Deak@nokia.com>]

Thanks! After changing vmlinux.lds.in as you suggest the problem goes
away. The relevant parts in Pass1 and Pass2 now:

Pass1:
D net_table     PTR     0xc02ae4a4
D _edata        PTR     0xc02ae554
B __bss_start   PTR     0xc02ae560
B system_state  PTR     0xc02ae560
B saved_command_line    PTR     0xc02ae564

Pass2:
D net_table     PTR     0xc02ae4a4
D _edata        PTR     0xc02e8a00
B __bss_start   PTR     0xc02e8a20
B system_state  PTR     0xc02e8a20
B saved_command_line    PTR     0xc02e8a24

So the order remains.

The patch for arm is included.

--Imre

> -----Original Message-----
> From: ext Keith Owens [mailto:kaos@ocs.com.au]
> Sent: 12 May, 2005 08:21
> To: Deak Imre (Nokia-M/Helsinki)
> Cc: linux-kernel@vger.kernel.org; Sam Ravnborg; Paulo Marques
> Subject: Re: arm: Inconsistent kallsyms data 
> 
> 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.
> 
>

Attachment: arm-kbuildfix-patch.diff
Description: arm-kbuildfix-patch.diff