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

[Alistair Francis]

On Tue, 2020-10-20 at 00:38 +0100, Jessica Clarke wrote:
> 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. 

That is annoying.

> 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 

Agreed, but I'm sure at least some of it could be upstreamed. That
helps us at least build test other platforms.

> 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 

That would be great!

> do
> know it required substantially less hacking than BBL though to get
> something that booted, especially in the build system.

I'm glad to hear that :)

Alistair

> 
> Jess
>