[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH9TF6PEusxj6f6UGD=wdzaWdikwJvrsAJdzgGPpCorstC=MkA@mail.gmail.com>
Date: Wed, 24 Jul 2024 01:12:33 +0200
From: Alex Rønne Petersen <alex@...xrp.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] riscv: Fix setjmp assembly when compiling for ilp32f/lp64f.
On Wed, Jul 24, 2024 at 12:58 AM Rich Felker <dalias@...c.org> wrote:
>
> On Wed, Jul 24, 2024 at 12:47:14AM +0200, Alex Rønne Petersen wrote:
> > On Tue, Jul 23, 2024 at 11:22 PM Szabolcs Nagy <nsz@...t70.net> wrote:
> > >
> > > * Alex Rønne Petersen <alex@...xrp.com> [2024-06-29 04:04:34 +0200]:
> > > > To keep things simple, I just changed the instruction mnemonics appropriately,
> > > > rather than adding complexity by changing the buffer size/offsets based on ABI.
> > > >
> > > > Signed-off-by: Alex Rønne Petersen <alex@...xrp.com>
> > >
> > > fwiw this looks good to me.
> > >
> > > the only weirdness is that the math code uses __riscv_flen
> > > and this code __riscv_float_abi*. i don't know if there
> > > is semantic difference.
> >
> > `__riscv_flen` tells you the width of the FP registers on the target
> > CPU. This is semantically distinct from `__riscv_float_abi`. For
> > example, while it would probably be a bit silly, there's no particular
> > reason why I couldn't target the LP64F ABI on an RV64IMAFDC machine.
> > In that case, no code needs to concern itself with the upper bits of
> > the FP registers.
> >
> > I took a quick peek at some of the `__riscv_flen` checks in musl. They
> > look ok. They're checking the capabilities of the machine for the
> > purposes of performing a computation; they're not making ABI
> > decisions. In my silly example above, if I tell the compiler to do so
> > with `-march=rv64...d`, it would theoretically be fine for the
> > compiler to generate double-precision float instructions for
> > computations as long as values are passed/returned according to LP64F
> > rules.
>
> If you're building code for -sf or -sp ABI, but could run on a machine
> with larger floating point register file, it's possible that the user
> could have libc built not to use fp registers at all or only 32-bit
> registers (respectively), but the calling application could be built
> for and running on a machine with 64-bit registers. In this case we
> need to understand what the ABI says. Are the 64-bit register, if
> present, call-saved in lower ABI levels where they don't participate
> in the calling convention? If so, no #ifdef is sufficient and there
> must be a runtime hwcap check here to determine which form of
> save/restore to do, like on arm and powerpc.
I don't think this is a scenario that the ABI considers to be
supported. If you try to link code of different ABIs, you will get
linker errors such as:
/tmp/ccz2Y86f.o: can't link soft-float modules with double-float modules
or
/tmp/cc7rTh7R.o: can't link single-float modules with double-float modules
(The direction does not matter.)
That said, if you think we should still try to do the right thing in
this scenario, I can read through the calling convention rules and try
to figure it out.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
