Le 29/11/2010 16:04, Heiko Schocher a écrit :
Hello Albert,
Albert ARIBAUD wrote:
I'll take a look this evening at builds with and without the SORT() from an ELF relocation tables perspective.
I debugged on the beagle board a little bit in this problem, and here what I found:
Hier it goes wrong:
arch/arm/cpu/armv7/start.S
fixloop: ldr r0, [r2] /* r0<- location to fix up, IN FLASH! */ 104: e5920000 ldr r0, [r2] add r0, r0, r9 /* r0<- location to fix up in RAM */ 108: e0800009 add r0, r0, r9
and later here
fixrel: /* relative fix: increase location by offset */ ldr r1, [r0]
Here the version with sort:
OMAP35xx>t;r Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x80008104 Current CPSR : 0x200001d3 (Supervisor) GPR00: 80008000 8ff1df84 80046d7c 8004d6ac GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6ac 00000000 GPR12: 00000000 8ff1df80 8000aef0 80008104 PC : 80008104 CPSR: 200001d3 OMAP35xx>t;r Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x80008108 Current CPSR : 0x200001d3 (Supervisor) GPR00: 00000000 8ff1df84 80046d7c 8004d6ac ^^^^^^^^ Ups... not good
GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6ac 00000000 GPR12: 00000000 8ff1df80 8000aef0 80008108 PC : 80008108 CPSR: 200001d3 OMAP35xx>t;r
Here without sort:
GPR00: 80008000 8ff1df84 80046d74 8004d6a4 GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6a4 00000000 GPR12: 00000000 8ff1df80 80010730 80008104 PC : 80008104 CPSR: 200001d3 OMAP35xx>ti;r Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x80008108 Current CPSR : 0x200001d3 (Supervisor) GPR00: 80008020 8ff1df84 80046d74 8004d6a4 ^^^^^^^^ Yep, thats better GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6a4 00000000 GPR12: 00000000 8ff1df80 80010730 80008108 PC : 80008108 CPSR: 200001d3 OMAP35xx>ti;r Core number : 0 Core state : debug mode (ARM) Debug entry cause : Single Step Current PC : 0x8000810c Current CPSR : 0x200001d3 (Supervisor)
System Map:
with sort:
80046d7c B __bss_start 80046d7c R __rel_dyn_start 80046d7c b timestamp 80046d80 b lastinc 80046d84 B gpmc_cfg
without sort:
80046d74 R __rel_dyn_start 80046d78 b htab 80046d84 B ___strtok 80046d88 B z_verbose
timestamp comes after the "__rel_dyn_end" entry in this case!
Further debugging pointed my that in:
in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets timestamp to 0, before relocation is executed, which leads that the memory @80046d7c gets overwritten to 0, which results in crashing in the fixrel case ...
So it seems to me the "sort" version intermix the "rel dyn" section entries with "normal" vars in bss ... Which raises the question:
Why is the rel.dyn Section in the bss section?
The .rel.dyn section is not "in" or "out" of the BSS: they are overlapped, i.e. they should start at the same address.
As indicated in the documentation, BSS should never be used before relocation; it actually *cannot* be written into by boards which start from NOR, and is set to zero for all boards right after relocation.
Since BSS does not exist before relocation, and .rel.dyn does not exist after relocation, they can use the same location: overlaying them is the best approach in order to get the smallest binary in Flash *and* the smallest image in RAM.
We can add code to try and catch the most obvious corruption of the relocation tables due to BSS being accessed before relocation, but we can't be sure to catch them all. The real solution is to fix the BSS usage.
bye, Heiko
Amicalement,