On Thu, 2019-11-07 at 00:12 +0200, Adrian Bunk wrote:
> On Wed, Nov 06, 2019 at 10:18:18AM -0800, Alistair Francis wrote:
> > ...
> > +TUNE_CCARGS_riscv64 .= "${@bb.utils.contains('TUNE_FEATURES',
> > 'riscv64-f', ' -mabi=lp64d', ' -mabi=lp64', d)}"
> > +TUNE_CCARGS_riscv32 .= "${@bb.utils.contains('TUNE_FEATURES',
> > 'riscv32-f', ' -mabi=ilp32f', ' -mabi=ilp32', d)}"
> > ...
>
> That looks wrong, what would you put in TUNE_FEATURES
> for -mabi=lp64f when -mabi=lp64d is called riscv64-f?
I am just going to add riscv32nf and riscv64nf. This will specify
-mabi=ilp32 and -mabi=lp64 accordingly. I won't change the default
riscv32 and riscv64. We can then deal with the single and double float
at a later point.
>
> Also note that this is only the floating point calling convention,
> whether the compiler emits floating point instructions is defined
> by -march.
-march is another can of worms that I was trying to avoid. I don't have
a good way of handling the ISA strings at the moment without some crazy
number of tune options.
We need to handle that but I think that should be in meta-riscv since I think for Linux we should just stick to rv64gc ABI and something cross distro agreed upon abi for riscv32 and bare metal is another story that’s where probably we need to address the ABIs
>
> It would be good if this would start with a plan how to handle
> all possible combination of RISC-V ISA extensions, ideally better
> than the arm mess.
Agreed. I am just going to change this to add a no float option as that
fixes a large number of 32-bit link failures (seen in U-Boot, OpenSBI
and SDKs) and we can re-evaluate a longer term march fix.
This is fine to start with for now
Alistair
>
> cu
> Adrian
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core