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:[email protected]] > Sent: 12 May, 2005 08:21 > To: Deak Imre (Nokia-M/Helsinki) > Cc: [email protected]; 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
- Prev by Date: Re: [XFS] Kernel (2.6.11) deadlock (kernel hang) in user mode when writing data through mmap on large files (64-bit systems)
- Next by Date: Re: [RFC/PATCH 0/5] add execute in place support
- Previous by thread: Re: arm: Inconsistent kallsyms data
- Next by thread: gettimeofday() goes backwards
- Index(es):
 |