On 03/19/2015 09:21 PM, Julius Werner wrote:
That said, I went back and looked at the assembly dump. It was using
0x14 as the size of the structure when sequencing through the entries.
001465dc R _bs_init_begin
001465e0 r cbmem_bscb
00146600 r gcov_bscb
0014663c R _bs_init_end
Each *entry* was aligned to 0x20. Just aligning the symbol wouldn't
have fixed it. That means we'd need to mark the structure declaration
as aligned to a specific value and annotate it accordingly in the
linker script. That's one route or just go w/ pointers to the
structures.
Yeah, that's what I was talking about in the first mail... I think
this means that the compiler would consider the sizeof() for each
structure to be 0x20. I'm pretty sure there's some kind of rule that
the sizeof() for any object must be evenly divisible by its minimum
alignment... that's how normal arrays work as well (e.g. if you had
struct mystruct { uint32_t a; uint8_t b; } and don't mark it
__packed__, then sizeof(struct mystruct) is 0x8 and an array of them
would have 3 bytes padding after each entry). So I'm pretty sure the
pointer++ mechanism to walk through it would've still worked if the
initial address had been right. (can we repro this? then we could
simply try it out instead of guessworking.)
Reproduction should be a simple matter of reverting 9ef9d859 on your
local tree and building for the ASUS KFSN4-DRE; the breakage was
extremely consistent and reproducible. The only wildcard would be that
gcc was building coreboot with specific optimisations for the AMD Fam10h
processor; you might need to force the appropriate flags set
(-mtune=amdfam10 ?) if building on some other CPU.
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
