lkml.org 
[lkml]   [2005]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: arm: Inconsistent kallsyms data
Date
From
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.
>
>
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-05-12 11:45    [W:0.035 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site