The idea to this patch is from Patrick Georgi but I reimplemented it from scratch since I can't reach the other box for a few days. It fixes stage0_i586.S assembling on the latest official GNU binutils version. Without this patch the compilation fails with:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: expecting operand after ','; got nothing /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: expecting operand after ','; got nothing
On 04.04.2008 04:40, Stefan Reinauer wrote:
The idea to this patch is from Patrick Georgi but I reimplemented it from scratch since I can't reach the other box for a few days. It fixes stage0_i586.S assembling on the latest official GNU binutils version. Without this patch the compilation fails with:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: expecting operand after ','; got nothing /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: expecting operand after ','; got nothing
Sorry, that patch only papers over the bug. If we ever decide to use CAR at another location, this will break again and we'll have to duplicate some of the code you touched in the patch. I'd prefer to know why a division fails, but a subtractoin succeeds.
Regards, Carl-Daniel
Am Freitag, den 04.04.2008, 08:04 +0200 schrieb Carl-Daniel Hailfinger:
On 04.04.2008 04:40, Stefan Reinauer wrote:
The idea to this patch is from Patrick Georgi but I reimplemented it from scratch since I can't reach the other box for a few days. It fixes stage0_i586.S assembling on the latest official GNU binutils version. Without this patch the compilation fails with:
/Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: expecting operand after ','; got nothing
Sorry, that patch only papers over the bug. If we ever decide to use CAR at another location, this will break again and we'll have to duplicate some of the code you touched in the patch. I'd prefer to know why a division fails, but a subtractoin succeeds.
parentheses fail in the gnuas macros. for some reason, when copying the arguments, gnu as (in that defective version) stops after the first closing ')', making the whole statement invalid.
My change (which this is based on) actually removed them all except the outermost level, but gnuas seems to be clever enough to remove unneeded parens before passing things on. That's possible if there are only subtractions, but not when mixed with divisions like in the original version.
The original code says this: extractmask (((\carsize - \windowoffset) / 0x1000) - 4), %eax
extractmask is a macro with 2 arguments, segs [== (((\carsize - \windowoffset) / 0x1000) - 4)] and reg [== %eax]. At some point, extractmask does: .if \segs <= 0
which should expand to .if (((\carsize - \windowoffset) / 0x1000) - 4) <= 0
but which - due to the bug - really expands to .if (((\carsize - \windowoffset) <= 0
et voila: "missing ')'"
Regards, Patrick Georgi
parentheses fail in the gnuas macros.
For reference, it is called "GNU assembler" or "GAS".
for some reason, when copying the arguments, gnu as (in that defective version) stops after the first closing ')', making the whole statement invalid.
What GAS versions fail? Steps to reproduce / standalone testcase?
Segher
Carl-Daniel Hailfinger wrote:
On 04.04.2008 04:40, Stefan Reinauer wrote:
The idea to this patch is from Patrick Georgi but I reimplemented it from scratch since I can't reach the other box for a few days. It fixes stage0_i586.S assembling on the latest official GNU binutils version. Without this patch the compilation fails with:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')'
[..]
Sorry, that patch only papers over the bug. If we ever decide to use CAR at another location, this will break again and we'll have to duplicate some of the code you touched in the patch. I'd prefer to know why a division fails, but a subtractoin succeeds.
Why is that code more position dependent than the previous, non-compiling code?
While I think, requiring the latest version of binutils (or, any other toolchain part, for that matter) is fair, we should not require features that do not work in the latest "stable" version but require a snapshot release to be installed.
Stefan
On 04.04.2008 15:08, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 04.04.2008 04:40, Stefan Reinauer wrote:
The idea to this patch is from Patrick Georgi but I reimplemented it from scratch since I can't reach the other box for a few days. It fixes stage0_i586.S assembling on the latest official GNU binutils version. Without this patch the compilation fails with:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:345: Error: missing ')'
[..]
Sorry, that patch only papers over the bug. If we ever decide to use CAR at another location, this will break again and we'll have to duplicate some of the code you touched in the patch. I'd prefer to know why a division fails, but a subtractoin succeeds.
Why is that code more position dependent than the previous, non-compiling code?
You hardcode the segment size to 4k. If we place the CAR area somewhere else, we have to deal with 16k and even 64k segments. The current code uses abstract segments as a unit and that abstraction is removed by the patch.
While I think, requiring the latest version of binutils (or, any other toolchain part, for that matter) is fair, we should not require features that do not work in the latest "stable" version but require a snapshot release to be installed.
It works in older versions. The version you used is buggy. There is no reason not to blacklist that broken version unless someone can prove that the new behaviour is correct according to any spec.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
While I think, requiring the latest version of binutils (or, any other toolchain part, for that matter) is fair, we should not require features that do not work in the latest "stable" version but require a snapshot release to be installed.
It works in older versions. The version you used is buggy. There is no reason not to blacklist that broken version unless someone can prove that the new behaviour is correct according to any spec.
That's plain wrong, sorry. I also used 2.17 and the error is the same. So the two latest stable versions of binutils don't work with that code. You won't get that code to translate unless you use an experimental version of binutils (snapshot).
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Stefan
On 04.04.2008 16:32, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
While I think, requiring the latest version of binutils (or, any other toolchain part, for that matter) is fair, we should not require features that do not work in the latest "stable" version but require a snapshot release to be installed.
It works in older versions. The version you used is buggy. There is no reason not to blacklist that broken version unless someone can prove that the new behaviour is correct according to any spec.
That's plain wrong, sorry. I also used 2.17 and the error is the same. So the two latest stable versions of binutils don't work with that code. You won't get that code to translate unless you use an experimental version of binutils (snapshot).
I stand corrected. We fixed one binutils problem with that piece of code in r3044 of v2, but the patch was not applied to v3. I have corrected that in r654 of v3.
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Can you retest with current HEAD? Thanks!
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Can you retest with current HEAD? Thanks!
Great! It reduced the number of errors:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' make: *** [/Users/stepan/Devel/coreboot-v3/build/arch/x86/stage0_i586.o] Error 1
I think this is getting there.
On 04.04.2008 17:57, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Can you retest with current HEAD? Thanks!
Great! It reduced the number of errors:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' make: *** [/Users/stepan/Devel/coreboot-v3/build/arch/x86/stage0_i586.o] Error 1
I think this is getting there.
Strange. The code now should be identical to what we use for v2 AMD CAR. I'll see what I can do. Probably some #define needs to be replaced with .set to fix the rest of the bug. I'll report back ASAP.
By the way, why are you working with the _generic_ x86 CAR code in v3 instead of porting the _AMD_ CAR code from v2 to v3?
Regards, Carl-Daniel
On 04.04.2008 18:51, Carl-Daniel Hailfinger wrote:
On 04.04.2008 17:57, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Can you retest with current HEAD? Thanks!
Great! It reduced the number of errors:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' make: *** [/Users/stepan/Devel/coreboot-v3/build/arch/x86/stage0_i586.o] Error 1
I think this is getting there.
Strange. The code now should be identical to what we use for v2 AMD CAR.
Actually, I think that any v2 AMD CAR target should fail as well on a machine having problems with this code in v3. Maybe there is a difference after preprocessing somewhere...
I'll see what I can do. Probably some #define needs to be replaced with .set to fix the rest of the bug. I'll report back ASAP.
By the way, why are you working with the _generic_ x86 CAR code in v3 instead of porting the _AMD_ CAR code from v2 to v3?
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
On 04.04.2008 19:49, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 04.04.2008 19:49, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
No doubt. But I am compiling coreboot, not Linux.
On Fri, Apr 04, 2008 at 12:01:34PM -0600, Stefan Reinauer wrote:
binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
No doubt. But I am compiling coreboot, not Linux.
I think the meaning was "found in Linux" rather than "meant for building Linux."
Yes, distributions are patch happy. Maybe simply because their timeframe is too different from upstream.
//Peter
On 04.04.2008 20:31, Peter Stuge wrote:
On Fri, Apr 04, 2008 at 12:01:34PM -0600, Stefan Reinauer wrote:
binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
No doubt. But I am compiling coreboot, not Linux.
I think the meaning was "found in Linux" rather than "meant for building Linux."
Indeed.
Yes, distributions are patch happy. Maybe simply because their timeframe is too different from upstream.
That, and sometimes it is difficult to get some "essential" patches merged upstream.
Regards, Carl-Daniel
binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
No doubt. But I am compiling coreboot, not Linux.
I think the meaning was "found in Linux" rather than "meant for building Linux."
I mean the thing that calls itself "linux binutils":
http://www.kernel.org/pub/linux/devel/binutils/
Long ago, in a galaxy far far away, this was relevant. Nowadays, no one should have a reason not to use binutils mainline.
Segher
On Fri, Apr 4, 2008 at 10:54 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
In an ideal world coreboot would be buildable on a wide variety of binutils versions, but it seems to me that coreboot uses a number of linker features that just aren't well exercised and only a few people on the planet understand at all, judging from bug discussions on the binutils lists. Since I'm not one of them, I choose to be lazy and stop fighting binutils bugs.
So with the latest Fedora upgrade, I gave up on using the Fedora binutils and now build a gnu.org one from scratch (along with a complete cross-compiling toolchain for building a Linux payload with busybox, uClibc, etc.--I'm happy to share the build scripts if anyone is interested).
FWIW.
--Ed
On Fri, Apr 04, 2008 at 11:07:55AM -0700, Ed Swierk wrote:
So with the latest Fedora upgrade, I gave up on using the Fedora binutils and now build a gnu.org one from scratch (along with a complete cross-compiling toolchain for building a Linux payload with busybox, uClibc, etc.--I'm happy to share the build scripts if anyone is interested).
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
//Peter
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
--Ed
On Friday 04 April 2008 20:43, Ed Swierk wrote:
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
What about a reference toolchain everybody can build on his host and use to compile coreboot? I believe we will out of luck to support every toolchain on this planet.
Juergen
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Juergen Beisert Sent: Friday, April 04, 2008 1:29 PM To: linuxbios@linuxbios.org Cc: Ed Swierk; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] fix stage0_i586.S in v3
On Friday 04 April 2008 20:43, Ed Swierk wrote:
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
What about a reference toolchain everybody can build on his host and use to compile coreboot? I believe we will out of luck to support every toolchain on this planet.
I think it is nicer to have a black list. Hopefully the build succeeds in more instances than it fails. Otherwise we might pick a reference toolchain that turns out to have bugs later.
Myles
On Friday 04 April 2008 21:34, Myles Watson wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Juergen Beisert Sent: Friday, April 04, 2008 1:29 PM To: linuxbios@linuxbios.org Cc: Ed Swierk; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] fix stage0_i586.S in v3
On Friday 04 April 2008 20:43, Ed Swierk wrote:
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
What about a reference toolchain everybody can build on his host and use to compile coreboot? I believe we will out of luck to support every toolchain on this planet.
I think it is nicer to have a black list. Hopefully the build succeeds in more instances than it fails. Otherwise we might pick a reference toolchain that turns out to have bugs later.
But it's easier to fix. You fix one reference toolchain and make everyone happy.
Black lists only gets bigger and bigger...
Juergen
On 04.04.2008 22:22, Juergen Beisert wrote:
On Friday 04 April 2008 21:34, Myles Watson wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Juergen Beisert Sent: Friday, April 04, 2008 1:29 PM To: linuxbios@linuxbios.org Cc: Ed Swierk; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] fix stage0_i586.S in v3
On Friday 04 April 2008 20:43, Ed Swierk wrote:
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
What about a reference toolchain everybody can build on his host and use to compile coreboot? I believe we will out of luck to support every toolchain on this planet.
I think it is nicer to have a black list. Hopefully the build succeeds in more instances than it fails. Otherwise we might pick a reference toolchain that turns out to have bugs later.
But it's easier to fix. You fix one reference toolchain and make everyone happy.
Black lists only gets bigger and bigger...
Turns out this was not about whitespace, but the "/" character used in the division was interpreted as a comment character if GNU as had been compiled for an i*86-elf target (commonly seen on MacOSX). Stefan committed a fix in r655.
Regards, Carl-Daniel
Juergen Beisert wrote:
On Friday 04 April 2008 20:43, Ed Swierk wrote:
On Fri, Apr 4, 2008 at 11:28 AM, Peter Stuge peter@stuge.se wrote:
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
And buildroot and LFS and lots of others too. I'm not knocking any of those, but they are more complex than what I was looking for. My 50-line shell script (attached) builds a cross-compiling gcc (4.2.2) + binutils (2.17) + uClibc (0.9.29) toolchain, nothing more.
What about a reference toolchain everybody can build on his host and use to compile coreboot? I believe we will out of luck to support every toolchain on this planet.
Juergen
Yes. It will end up in something like this.
On 04.04.2008 20:28, Peter Stuge wrote:
On Fri, Apr 04, 2008 at 11:07:55AM -0700, Ed Swierk wrote:
So with the latest Fedora upgrade, I gave up on using the Fedora binutils and now build a gnu.org one from scratch (along with a complete cross-compiling toolchain for building a Linux payload with busybox, uClibc, etc.--I'm happy to share the build scripts if anyone is interested).
Also there is crossdev and just plain Gentoo, either just vanilla binutils ebuilds or even catalyst for a complete custom system build.
Can all of you please try to build the qemu target in v3 (preferably svn HEAD)? It is really easy (make distclean; make menuconfig; make), leave all settings at the default in menuconfig, then simply exit with saving the configuration.
I would be very interested in build/arch/x86/stage0_asm.s if the build fails for you.
Regards, Carl-Daniel
On Fri, Apr 04, 2008 at 08:59:50PM +0200, Carl-Daniel Hailfinger wrote:
Can all of you please try to build the qemu target in v3 (preferably svn HEAD)?
654 builds here. Gentoo with binutils-2.18-r1 which means
mirror://kernel/linux/devel/binutils/binutils-2.18.tar.bz2 mirror://kernel/linux/devel/binutils/test/binutils-2.18.tar.bz2 mirror://gnu/binutils/binutils-2.18.tar.bz2
plus
http://dev.gentoo.org/~vapier/dist/binutils-2.18-patches-1.5.tar.bz2
If I understood Segher correctly those three binutils-2.18.tar.bz2 are not exactly the same? Strange!
//Peter
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
Not a "completely different beast", but please do us a favour and try with FSF binutils before reporting problems :-)
Segher
On 04.04.2008 21:11, Segher Boessenkool wrote:
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
Not a "completely different beast", but please do us a favour and try with FSF binutils before reporting problems :-)
It seems that the FSF binutils are broken and the versions shipped by distributors are OK. It was rumored that the failing build happened on MacOS, if that helps any.
My best guess at what is failing for Stefan is attached. The failing line is the one calling the simplemask macro.
Regards, Carl-Daniel
# 1 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" # 1 "<built-in>" # 1 "<command-line>" # 1 "/sources/tmptrees/LinuxBIOSv3-tmp/build/config.h" 1 # 1 "<command-line>" 2 # 1 "/sources/tmptrees/LinuxBIOSv3-tmp/build/build.h" 1 # 1 "<command-line>" 2 # 1 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" ## ## This file is part of the coreboot project. ## ## Copyright (C) 2000,2007 Ronald G. Minnich rminnich@gmail.com ## Copyright (C) 2005 Eswar Nallusamy, LANL ## Copyright (C) 2005 Tyan ## (Written by Yinghai Lu yhlu@tyan.com for Tyan) ## Copyright (C) 2007 coresystems GmbH ## (Written by Stefan Reinauer stepan@coresystems.de for coresystems GmbH) ## ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; version 2 of the License. ## ## This program is distributed in the hope that it will be useful, ## but WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this program; if not, write to the Free Software ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ##
# init code - switch cpu to pmode and enable cache as ram.
# 1 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/macros.h" 1 # 28 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" 2
.code16 .globl _stage0 _stage0: cli
movl %eax, %ebp; # 49 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" xorl %eax, %eax movl %eax, %cr3 # 59 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" data32 lgdt %cs:gdtptr
movl %cr0, %eax andl $0x7FFAFFD1, %eax orl $0x60000001, %eax movl %eax, %cr0
movl %ebp, %eax
data32 ljmp $0x08, $protected_stage0
#.byte 0x66 .code32 #ljmp $0x08, $protected_stage0
#.code16 .align 4 .globl gdt16 gdt16 = . - _stage0 gdt16x: .word gdt16xend - gdt16x -1 .long gdt16x .word 0
.word 0xffff, 0x0000 .byte 0x00, 0x9b, 0xcf, 0x00
.word 0xffff, 0x0000 .byte 0x00, 0x93, 0xcf, 0x00 gdt16xend:
.code32 # 111 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" .align 4 .globl gdtptr .globl gdt_limit gdt_limit = gdt_end - gdt - 1
gdt: gdtptr: .word gdt_end - gdt -1 .long gdt .word 0
.word 0xffff, 0x0000 .byte 0x00, 0x9b, 0xcf, 0x00
.word 0xffff, 0x0000 .byte 0x00, 0x93, 0xcf, 0x00
.word 0xffff, 0x0000 .byte 0x00, 0x9b, 0xcf, 0x00
.word 0xffff, 0x0000 .byte 0x00, 0x93, 0xcf, 0x00 gdt_end: # 151 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" .align 4 .globl protected_stage0 protected_stage0:
lgdt %cs:gdtptr ljmp $0x08, $__protected_stage0
.globl __protected_stage0 __protected_stage0:
movl %eax, %ebp
movb $0x01, %al; outb %al, $0x80
movw $0x10, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss movw %ax, %fs movw %ax, %gs
movl %ebp, %eax
.align 4 # 191 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" # 1 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/mtrr.h" 1 # 192 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" 2
movl %eax, %ebp
CacheAsRam:
movl $01, %eax cpuid btl $28, %edx jnc NotHtProcessor bswapl %ebx cmpb $01, %bh jbe NotHtProcessor # 215 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" xorl %eax, %eax xorl %edx, %edx movl $0x250, %ecx wrmsr
movl $0xFEE00020, %esi movl (%esi), %ebx andl $0xFF000000, %ebx bswapl %ebx btl $0, %ebx jnc LogicalAP0 andb $0xFE, %bl jmp SendSIPI LogicalAP0: orb $0x01, %bl SendSIPI: bswapl %ebx
RetrySIPI: movl %ebx, %eax movl $0xFEE00310, %esi movl %eax, (%esi)
movl $0x000006F9, %eax movl $0xFEE00300, %esi movl %eax, (%esi)
movl $0x30, %ecx SIPIDelay: pause decl %ecx jnz SIPIDelay
movl (%esi), %eax andl $0x00001000, %eax jnz RetrySIPI
LogicalAPSIPINotdone: movl $0x250, %ecx rdmsr orl %eax, %eax jz LogicalAPSIPINotdone
NotHtProcessor:
movl $0x2ff, %ecx xorl %edx, %edx
movl $0x00000c00, %eax wrmsr
xorl %edx, %edx movl $fixed_mtrr_msr, %esi clear_fixed_var_mtrr: lodsl (%esi), %eax testl %eax, %eax jz clear_fixed_var_mtrr_out
movl %eax, %ecx xorl %eax, %eax wrmsr
jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out:
.macro extractmask segs, reg .if \segs <= 0
xorl \reg, \reg .elseif \segs == 1 movl $0x06000000, \reg .elseif \segs == 2 movl $0x06060000, \reg .elseif \segs == 3 movl $0x06060600, \reg .elseif \segs >= 4 movl $0x06060606, \reg .endif .endm
.macro simplemask carsize, windowoffset .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000) - 4) extractmask gas_bug_workaround, %eax .set gas_bug_workaround,(((\carsize - \windowoffset) / 0x1000)) extractmask gas_bug_workaround, %edx
.endm # 351 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" movl $0x269, %ecx simplemask 0x1000, 0 wrmsr # 371 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" movl %cr0, %eax andl $0x9fffffff,%eax movl %eax, %cr0
movl $0x8f000, %esi cld movl $(0x1000>>2), %ecx rep lodsl
movl $0x8f000, %edi movl $(0x1000>>2), %ecx xorl %eax, %eax rep stosl # 433 "/sources/tmptrees/LinuxBIOSv3-tmp/arch/x86/stage0_i586.S" movl $(0x8f000 +0x1000 -4), %eax movl %eax, %esp
movw $0x20, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss
lout:
movl $0x8f000, %eax pushl %eax
movl %ebp, %eax
movl %esp, %ebp pushl %eax call stage1_main
fixed_mtrr_msr: .long 0x250, 0x258, 0x259 .long 0x268, 0x269, 0x26A .long 0x26B, 0x26C, 0x26D .long 0x26E, 0x26F var_mtrr_msr: .long 0x200, 0x201, 0x202, 0x203 .long 0x204, 0x205, 0x206, 0x207 .long 0x208, 0x209, 0x20A, 0x20B .long 0x20C, 0x20D, 0x20E, 0x20F .long 0x000
# Reset vector.
SEGMENT_SIZE = 0x10000 RVECTOR = 0x00010 # Due to YET ANOTHER BUG in GNU bintools, you can NOT have a code16 here. # I think we should leave it this way forever, as the bugs come and # go -- and come again. # .code16 # .section ".rom.text" .section ".reset", "ax" .globl _resetjump _resetjump:
# jmp _stage0 .byte 0xe9 .int _stage0 - ( . + 2 )
.byte 0
# Date? ID string? We might want to put something else in here. .ascii "2008/04/04"
# Checksum. #.word 0
Segher Boessenkool wrote:
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
Not at all. Just build the Qemu target with a freshly checked out tree and an official version of binutils from gnu.org
By the way, IIRC Segher once wrote that binutils from gnu.org are a completely different beast compared to "linux binutils" shipped by almost all distributors.
Not a "completely different beast", but please do us a favour and try with FSF binutils before reporting problems :-)
Hello, Segher,
I am reporting with FSF binutils, because using non-FSF linux specific binutils is currently not an option here. I want coreboot to compile with the FSF version of binutils, hence the patch to v3 I sent yesterday.
On 04.04.2008 19:06, Carl-Daniel Hailfinger wrote:
On 04.04.2008 18:51, Carl-Daniel Hailfinger wrote:
On 04.04.2008 17:57, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Can you retest with current HEAD? Thanks!
Great! It reduced the number of errors:
AS build/arch/x86/stage0_i586.o /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S: Assembler messages: /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' /Users/stepan/Devel/coreboot-v3/arch/x86/stage0_i586.S:352: Error: missing ')' make: *** [/Users/stepan/Devel/coreboot-v3/build/arch/x86/stage0_i586.o] Error 1
I think this is getting there.
Strange. The code now should be identical to what we use for v2 AMD CAR.
Actually, I think that any v2 AMD CAR target should fail as well on a machine having problems with this code in v3. Maybe there is a difference after preprocessing somewhere...
Please include build/arch/x86/stage0_asm.s in your reply. We should be able to reduce that file to a simple testcase. Maybe you want to CC: Segher in your reply.
I'll see what I can do. Probably some #define needs to be replaced with .set to fix the rest of the bug. I'll report back ASAP.
By the way, why are you working with the _generic_ x86 CAR code in v3 instead of porting the _AMD_ CAR code from v2 to v3?
Do you have any patch which would help me reproduce the issue? The v3 tree currently lacks a target using the code in question.
I take that back. The qemu target in v3 compiles fine for me and it uses that file. I have an i686 openSUSE 10.3 system with GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Strange. The code now should be identical to what we use for v2 AMD CAR. I'll see what I can do. Probably some #define needs to be replaced with .set to fix the rest of the bug. I'll report back ASAP.
By the way, why are you working with the _generic_ x86 CAR code in v3 instead of porting the _AMD_ CAR code from v2 to v3?
Excuse me, I don't understand your question. I just try to compile coreboot v3 for Qemu.
Stefan
On 04.04.2008 19:47, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Strange. The code now should be identical to what we use for v2 AMD CAR. I'll see what I can do. Probably some #define needs to be replaced with .set to fix the rest of the bug. I'll report back ASAP.
By the way, why are you working with the _generic_ x86 CAR code in v3 instead of porting the _AMD_ CAR code from v2 to v3?
Excuse me, I don't understand your question. I just try to compile coreboot v3 for Qemu.
Ah sorry, I thought you were trying to port K8 to v3.
Regards, Carl-Daniel
It works in older versions. The version you used is buggy. There is no reason not to blacklist that broken version unless someone can prove that the new behaviour is correct according to any spec.
That's plain wrong, sorry. I also used 2.17 and the error is the same. So the two latest stable versions of binutils don't work with that code. You won't get that code to translate unless you use an experimental version of binutils (snapshot).
There is nothing "experimental" about binutils mainline.
So either we get this problem solved differently or I'll have to go ahead and check the patch in. Relying on experimental toolchains is not an option. Even if your toolchain provider uses experimental binutils versions, that's nothing we should enforce.
Not if there's a sane workaround, no.
Segher
-
Carl-Daniel Hailfinger -
Ed Swierk -
Juergen Beisert -
Myles Watson -
Patrick Georgi -
Peter Stuge -
Segher Boessenkool -
Stefan Reinauer