[coreboot] GCC update broke AMD Fam10h boot

[Aaron Durbin]

On Thu, Mar 19, 2015 at 7:21 PM, Julius Werner <jwerner at chromium.org> 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.)

I think you misunderstood what I wrote; I wasn't guessworking.

The bscb structure arrays were aligned to 0x20. But the structure size
to the compiler is 0x14. It's 0x14 in gdb and it's 0x14 in the
instructions calculating the next entry. That's how I diagnosed this
to begin with. From 4.92/ramstage.debug:

  145991:       bb dc 65 14 00          mov    $0x1465dc,%ebx
...
  145a36:       81 fb 3c 66 14 00       cmp    $0x14663c,%ebx
  145a3c:       74 5f                   je     145a9d <main+0x11c>
...
  145a8a:       83 c3 14                add    $0x14,%ebx
...
 145a9b:       eb 99                   jmp    145a36 <main+0xb5>

So we know the first entry in the array is wrong based on
_bs_init_begin != cbmem_bscb. However, ignoring that the entry after
cbmem_bscb is wrong too because the 0x14 increment will not result in
resolving to gcov_bscb.

-Aaron