Messages in this thread | | | Subject | RE: arm: Inconsistent kallsyms data | Date | Thu, 12 May 2005 12:40:16 +0300 | 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] | |