All,
Just a heads up as there is no bugtracker for this project. GIT commit
53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2,
breaks ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39
POST code, but then goes into an infinite loop). Downgrading the GCC
versio
On Sunday, March 15, 2015 02:04:51 PM Timothy Pearson wrote:
> All,
>
> Just a heads up as there is no bugtracker for this project. GIT commit
> 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2,
> breaks ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39
> POST cod
On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
wrote:
> All,
>
> Just a heads up as there is no bugtracker for this project. GIT commit
> 53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2, breaks
> ramstage on AMD Fam10h systems (ramstage loads, sends its 0x39 POST code,
> bu
On 03/16/2015 09:23 AM, Aaron Durbin wrote:
On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
wrote:
All,
Just a heads up as there is no bugtracker for this project. GIT commit
53c388fe, which updates the crossgcc GCC version from 4.8.3 to 4.9.2, breaks
ramstage on AMD Fam10h systems (ramstag
On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson
wrote:
> On 03/16/2015 09:23 AM, Aaron Durbin wrote:
>>
>> On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
>> wrote:
>>>
>>> All,
>>>
>>> Just a heads up as there is no bugtracker for this project. GIT commit
>>> 53c388fe, which updates the cros
On 03/16/2015 04:44 PM, Aaron Durbin wrote:
On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson
wrote:
On 03/16/2015 09:23 AM, Aaron Durbin wrote:
On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
wrote:
All,
Just a heads up as there is no bugtracker for this project. GIT commit
53c388fe,
On Mon, Mar 16, 2015 at 4:49 PM, Timothy Pearson
wrote:
> On 03/16/2015 04:44 PM, Aaron Durbin wrote:
>>
>> On Mon, Mar 16, 2015 at 1:39 PM, Timothy Pearson
>> wrote:
>>>
>>> On 03/16/2015 09:23 AM, Aaron Durbin wrote:
On Sun, Mar 15, 2015 at 2:04 PM, Timothy Pearson
wrote
* Aaron Durbin [150316 22:44]:
> A quick hack is add ALIGN(32) to the linker script before
> _bs_init_begin: src/arch/x86/ramstage.ld
>
> But I think we'll need to store pointers to the structures in order to
> properly handle the situation where the compiler is effectively making
> alignment/siz
On Mon, Mar 16, 2015 at 4:33 PM, Stefan Reinauer
wrote:
> * Aaron Durbin [150316 22:44]:
>> A quick hack is add ALIGN(32) to the linker script before
>> _bs_init_begin: src/arch/x86/ramstage.ld
>>
>> But I think we'll need to store pointers to the structures in order to
>> properly handle the sit
Sounds like this could've been solved with a simple ALIGN(8) in the
ldscript, right? I don't know what made the compiler think that it
would have to align i386 pointers to 8 byte (which seems to be what
happened), but if it makes that decision then it should also conclude
that sizeof(struct boot_st
On Thu, Mar 19, 2015 at 5:29 PM, Julius Werner wrote:
> Sounds like this could've been solved with a simple ALIGN(8) in the
> ldscript, right? I don't know what made the compiler think that it
> would have to align i386 pointers to 8 byte (which seems to be what
> happened), but if it makes that d
> You are right that it would work, but back solving for which alignment
> the compiler decided is hard. It's definitely whack-a-mole in that
> case. It could have very well decided 16 too. Without any insight as
> to why that breaks down. Or you go the route of putting alignments on
> structures j
On Thu, Mar 19, 2015 at 3:54 PM, Julius Werner wrote:
>> You are right that it would work, but back solving for which alignment
>> the compiler decided is hard. It's definitely whack-a-mole in that
>> case. It could have very well decided 16 too. Without any insight as
>> to why that breaks down.
> 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
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
On Thu, Mar 19, 2015 at 7: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
> 145a8a: 83 c3 14add$0x14,%ebx
Okay, sorry, I didn't know you looked that closely into this. That's
quite unrefuteable.
The only question that I still have is then WTF the compiler was
thinking... this just sounds like a plain bug somewhere (but I agree
that doesn't r
On Thu, Mar 19, 2015 at 7:53 PM, Julius Werner wrote:
>> 145a8a: 83 c3 14add$0x14,%ebx
>
> Okay, sorry, I didn't know you looked that closely into this. That's
> quite unrefuteable.
>
> The only question that I still have is then WTF the compiler was
> thinking... this
18 matches
Mail list logo
