[PATCH] Makefile: Don't specify mabi or march

[Jessica Clarke]

On 20 Oct 2020, at 00:32, Alistair Francis <Alistair.Francis at wdc.com> wrote:
> On Tue, 2020-10-20 at 00:05 +0100, Jessica Clarke wrote:
>> On 20 Oct 2020, at 00:02, Alistair Francis <alistair.francis at wdc.com>
>> wrote:
>>> On Mon, 2020-10-19 at 23:56 +0100, Jessica Clarke wrote:
>>>> On 19 Oct 2020, at 23:41, Alistair Francis <
>>>> alistair.francis at wdc.com>
>>>> wrote:
>>>>> To avoid
>>>>>  can't link double-float modules with soft-float modules
>>>>> errors when building 32-bit openSBI don't specify mabi or
>>>>> march.
>>>> 
>>>> What happens if you want to build for a different ABI or ISA
>>>> string
>>>> deliberately? Especially with something like Clang where every
>>>> compiler
>>>> is a cross-compiler. Users should be able to specify an ABI or
>>>> ISA
>>>> string if they want and have it honoured, either via
>>>> PLATFORM_RISCV_ABI/ISA or by using += for CFLAGS everywhere
>>>> rather
>>>> than
>>>> overwriting it entirely (which is the more standard thing to do
>>>> for
>>>> software that isn't RISC-V-specific).
>>> 
>>> A user could do that by specifying their own CFLAGS when building
>>> to
>>> allow them to specify a ISA or ABI.
>> 
>> Makefile:196:CFLAGS		=	-g -Wall -Werror -ffreestanding
>> -nostdlib -fno-strict-aliasing -O2
> 
> Ah, I didn't realise this. I'll change it to a +=

Thanks. Same goes for AFLAGS, and I didn't check LDFLAGS etc.

>> That doesn't work so well with user-supplied CFLAGS.
>> 
>>> Currently no platform set PLATFORM_RISCV_ABI as it defaults to
>>> ilp32 or
>>> lp64.
>> 
>> We do. We have new ABIs for our extension (see cheri-cpu.org).
> 
> Ah ok. Maybe it's worth upstreamign the cheri implementaiton then?

We never really finished it properly and have been stuck on BBL. Well,
in theory it works, but it just hasn't seen the same amount of testing
as it's not in day-to-day use. I don't think it makes much sense to
upstream the very CHERI-specific bits (instructions, configuration,
etc) since it's ultimately a research architecture for now and we do
want to be able to make breaking changes, but there may well be things
we can upstream that make our fork's diff smaller (the nature of the
architecture and software model means that we routinely find
integer/pointer confusion in projects and can upstream many of our
diffs as simple code quality improvements to use the right type). I do
know it required substantially less hacking than BBL though to get
something that booted, especially in the build system.

Jess