Dear lists, After review my cross-compiler patch, I found it does not work as expect. We use a script called xcompile to set and verify the compile toolchain. Must we use it? Can we just trust our users to let them set their compiler prefix by themselves? If so, we can add cross-compiler for ARM easily. If not, How could I add cross-compiler support to xcompile? I just read the code when we supported PPC and alpha, but It has changed a lot since then.
Thanks, Hamo
Am 08.05.2011 07:04, schrieb Hamo:
for ARM easily. If not, How could I add cross-compiler support to xcompile? I just read the code when we supported PPC and alpha, but It has changed a lot since then.
Maybe: - Rename CC, AS, ... to I386_CC, I386_AS, ...
- Add support to check for other architectures (there's already a comment "This should be a loop over all supported architectures", storing that in ARM_CC, ARM_AS, ...
- Change Makefile to set: CC:=$($(CONFIG_SOME_CONFIG_VARIABLE_WITH_ARCHITECTURE))_CC ... depending on the chosen target hardware
Patrick
On Mon, May 9, 2011 at 2:09 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 08.05.2011 07:04, schrieb Hamo:
for ARM easily. If not, How could I add cross-compiler support to xcompile? I just read the code when we supported PPC and alpha, but It has changed a lot since then.
Maybe:
Rename CC, AS, ... to I386_CC, I386_AS, ...
Add support to check for other architectures (there's already a
comment "This should be a loop over all supported architectures", storing that in ARM_CC, ARM_AS, ...
- Change Makefile to set:
CC:=$($(CONFIG_SOME_CONFIG_VARIABLE_WITH_ARCHITECTURE))_CC ... depending on the chosen target hardware
Patrick
There are a few gcc toolchain prefixes such as arm-elf, armel-elf, arm-none-eabi, etc. It is a little difficult hard coding all the prefixes in this script. And Such as U-boot and Kernel, both allow their users set their own toolchain prefix.
Hamo wrote:
There are a few gcc toolchain prefixes such as arm-elf, armel-elf, arm-none-eabi, etc. It is a little difficult hard coding all the prefixes in this script. And Such as U-boot and Kernel, both allow their users set their own toolchain prefix.
I think it would be OK to require one specific prefix. I would suggest arm-none-eabi because it is correct, very widely used and also because it is what CodeSourcery G++ Lite uses.
//Peter
On Mon, May 9, 2011 at 2:04 PM, Peter Stuge peter@stuge.se wrote:
Hamo wrote:
There are a few gcc toolchain prefixes such as arm-elf, armel-elf, arm-none-eabi, etc. It is a little difficult hard coding all the prefixes in this script. And Such as U-boot and Kernel, both allow their users set their own toolchain prefix.
I think it would be OK to require one specific prefix. I would suggest arm-none-eabi because it is correct, very widely used and also because it is what CodeSourcery G++ Lite uses.
If so, Could I use the idea of Patrick, create variables CC_$(ARCH), AS_$(ARCH), LD_$(ARCH) and etc. in script xcompile and assign them to $(CC), $(AS), $(LD) and so on when the user has selected their ARCH?
//Peter
Hamo wrote:
If so, Could I use the idea of Patrick, create variables CC_$(ARCH), AS_$(ARCH), LD_$(ARCH) and etc. in script xcompile and assign them to $(CC), $(AS), $(LD) and so on
I think this is a good approach.
when the user has selected their ARCH?
Remember that we may want ARCH to be set by mainboards rather than users. This might become important because xcompile usually runs also before configuration.
//Peter
Am 09.05.2011 14:36, schrieb Peter Stuge:
Remember that we may want ARCH to be set by mainboards rather than users. This might become important because xcompile usually runs also before configuration.
That's why (in my proposal) the actual assignment is done in the Makefile, not in xcompile. xcompile lists _all_ candidate toolchains it finds, Makefile selects the one for the current build out of those given by xcompile.
Patrick
Am 09.05.2011 05:00, schrieb Hamo:
There are a few gcc toolchain prefixes such as arm-elf, armel-elf, arm-none-eabi, etc. It is a little difficult hard coding all the prefixes in this script. And Such as U-boot and Kernel, both allow their users set their own toolchain prefix.
We mostly care about what crossgcc creates. Other toolchains work (or not) at the user's risk.
Patrick
On Mon, May 9, 2011 at 4:03 PM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 09.05.2011 05:00, schrieb Hamo:
There are a few gcc toolchain prefixes such as arm-elf, armel-elf, arm-none-eabi, etc. It is a little difficult hard coding all the prefixes in this script. And Such as U-boot and Kernel, both allow their users set their own toolchain prefix.
We mostly care about what crossgcc creates. Other toolchains work (or not) at the user's risk.
You mean that we need using crossgcc creates our own ARM-gcc cross toolchain? Why must we do this? Could we just trust the famous and mostly used toolchain like g++? In this script, it says that it could not create an ARM toolchain. Should I fix it?
Patrick
Am 09.05.2011 13:50, schrieb Hamo:
You mean that we need using crossgcc creates our own ARM-gcc cross toolchain? Why must we do this? Could we just trust the famous and mostly used toolchain like g++?
"mostly used" is probably an overstatement. There are probably more ARM toolchains out there than linux distros (which were our main concern with requiring buildgcc toolchains, given how they all managed to mess up gcc for us). I expect the same kind of trouble with all these, so we'd better have some standard toolchain around that we can point people to.
In that case if/when people chose to use their own toolchains and things break, that's their problem, not ours.
In this script, it says that it could not create an ARM toolchain. Should I fix it?
That script was originally created for building ARM toolchains, before we repurposed it for coreboot uses (because of the toolchain mess hinted at above).
It should be enough to run "buildgcc -p arm-elf" (or arm-none-eabi or something), with maybe a bugfix here or there.
Patrick
On 09/05/11 21:58, Patrick Georgi wrote:
Am 09.05.2011 13:50, schrieb Hamo:
You mean that we need using crossgcc creates our own ARM-gcc cross toolchain? Why must we do this? Could we just trust the famous and mostly used toolchain like g++?
"mostly used" is probably an overstatement. There are probably more ARM toolchains out there than linux distros (which were our main concern with requiring buildgcc toolchains, given how they all managed to mess up gcc for us). I expect the same kind of trouble with all these, so we'd better have some standard toolchain around that we can point people to.
In that case if/when people chose to use their own toolchains and things break, that's their problem, not ours.
In this script, it says that it could not create an ARM toolchain. Should I fix it?
That script was originally created for building ARM toolchains, before we repurposed it for coreboot uses (because of the toolchain mess hinted at above).
It should be enough to run "buildgcc -p arm-elf" (or arm-none-eabi or something), with maybe a bugfix here or there.
Patrick
Might be worth talking to the U-Boot guys - They have a LOT of experience with toolchain issues (particularly ARM and the EABI)
Regards,
Graeme
-
Graeme Russ -
Hamo -
Patrick Georgi -
Peter Stuge