[coreboot] GCC update broke AMD Fam10h boot

[Timothy Pearson]

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