[Bug target/111065] New: [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[Bug target/111065] New: [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

            Bug ID: 111065
           Summary: [RISCV] t-linux-multilib specifies incorrect multilib
                    reuse patterns
           Product: gcc
           Version: og13 (devel/omp/gcc-13)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tommy_murphy at hotmail dot com
  Target Milestone: ---

The file gcc/config/riscv/t-linux-multilib:

*
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/t-linux-multilib

specifies the RISC-V multilibs to be built when --enable-multilib is passed at
configuration time:

*
https://github.com/riscv-collab/riscv-gnu-toolchain#installation-newliblinux-multilib

It also specifies multilib reuse patterns. These control what (if any) multilib
is (re)used when an arch/abi is specified at compile time (using -march=...
-mabi=...) for which no specific multilib exists. For example:

* rv64imafdc-lp64d-rv64imafd-

This specifies that the multilib for rv64imafdc/lp64d be built at toolchain
build time, and that it also be (re)used for the arch/abi rv64imafd/lp64d when
-march=rv64imafd -mabi=lp64d is passed at compile time.

In this case this reuse mapping will lead to problems if the target platform
(hardware, simulator etc.) strictly supports rv64imafd/lp64d but
libraries/startup code for rv64imafdc/lp64d are linked. This is because the
latter will most likely use RISC-V compressed instructions (via the RISC-V
optional C/Compressed extension) which the rv64imafd/lp64d target will not
support and will trap on. 

Multilib reuse mappings should always be from an arch/abi "superset" to a
"subset" of extensions. For example:

* reusing rv64imafd/lp64d for a rv64imafdc/lp64d target is OK - it just doesn't
take advantage of the C (Compressed) extension
* reusing rv64imafdc/lp64d for a rv64imafd/lp64d target is not OK - the
libraries will most likely use C (Compressed) instructions which the latter
target does not support and will trap on.

According to this comment:

*
https://github.com/gcc-mirror/gcc/blob/35b5762a740d4506d7acac65d0f8375640362492/gcc/config/riscv/t-linux-multilib#L2C1-L3C1

This is the list of multilibs/reuse patterns specified:

* rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-
* rv32imafdc-ilp32d-rv32imafd- 
* rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
* rv64imafdc-lp64d-rv64imafd-

all of which seem problematic/erroneous because they specify the reuse of
libraries with compressed instructions for arch/abi's that do not support the C
(Compressed) extension.

However I am loath to submit a patch because I am not sure what the
correct/authoritative list of multilibs and reuse patterns *should be* and what
disturbance may be caused by changing this file.

Maybe one of the seasoned RISC-V GCC contributors might be able to comment?

Thanks.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[kito at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

Kito Cheng <kito at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|og13 (devel/omp/gcc-13)     |14.0
                 CC|                            |kito at gcc dot gnu.org

--- Comment #1 from Kito Cheng <kito at gcc dot gnu.org> ---
One major issue around multilib for linux is we only encode abi to the path, so
it hard to extend that like baremetal toolchain.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

--- Comment #2 from Tommy Murphy <tommy_murphy at hotmail dot com> ---
Thanks @Kito Cheng - but I don't really understand how your comment relates to
the specific issue of the t-linux-multilib reuse "mappings" being incorrect
(and possibly the reverse of what was originally intended?)? Maybe you can
clarify? Thanks again.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[palmer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palmer at gcc dot gnu.org

--- Comment #3 from palmer at gcc dot gnu.org ---
(In reply to Tommy Murphy from comment #2)
> Thanks @Kito Cheng - but I don't really understand how your comment relates
> to the specific issue of the t-linux-multilib reuse "mappings" being
> incorrect (and possibly the reverse of what was originally intended?)? Maybe
> you can clarify? Thanks again.

The Linux and ELF multilibs are different: for Linux we assumed ISA
compatibility was up to the distro, so multilib just handles the ABI side of
things.  That said, C does bleed into the ABI so we should really fix that --
presumably we'd need some psABI work there, compatibility is going to be a bit
clunky so it's probably best to just add two explicit ABI variants.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[kito at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

--- Comment #4 from Kito Cheng <kito at gcc dot gnu.org> ---
I guess I skip too much detail here, the multilib for linux isn’t really honor
to the reause rule in the multilib config file for a while.

That just control how multilib build, e.g. build ilp32 with which arch, and we
will find matched ABI, but why we did that? The reason is simplify the reuse
rule, RISC-V has huge number of extension now, so enumeration the possible
combination are almost impossible.

But why it can’t use same scheme as baremetal? Okay, that’s because we encode
the abi in the path only, unlike baremetal we have encode both abi and arch, it
kinda of de facto ABI in linux/glibc, also it not make too much sense to having
too much different multilib within a (RISC-V) linux system.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

--- Comment #5 from Tommy Murphy <tommy_murphy at hotmail dot com> ---
Thanks for the comments Palmer and Kito.

However I'm still a bit confused. Is it the case that the multilib patterns
(for the "base" lib and reuse patterns) are interpreted/used differently in the
context of t-linux-multilib versus t-elf-multilib? And my interpretation was
incorrect for the former even if it is correct for the latter?

If any of this renders this bug report moot then just let me know or close it
off if necessary.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

--- Comment #6 from Tommy Murphy <tommy_murphy at hotmail dot com> ---
Hi Kito/Palmer - should I maybe close this issue here and take it up in the
riscv-gnu-toolchain/riscv-gcc repos instead? 

* https://github.com/riscv-collab/riscv-gnu-toolchain
* https://github.com/riscv-collab/riscv-gcc

It sounds like the issue of RISC-V multilib specification and management needs
some work and has (at least in the case of the Linux toolchain) diverged from
what was previously intended and what is currently documented with regard to
the multilib-generator script etc.

*
https://github.com/riscv-collab/riscv-gnu-toolchain#installation-newliblinux-multilib

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065

--- Comment #7 from Tommy Murphy <tommy_murphy at hotmail dot com> ---
(In reply to palmer from comment #3)
> The Linux and ELF multilibs are different: for Linux we assumed ISA
> compatibility was up to the distro, so multilib just handles the ABI side of
> things.  That said, C does bleed into the ABI so we should really fix that
> -- presumably we'd need some psABI work there, compatibility is going to be
> a bit clunky so it's probably best to just add two explicit ABI variants.

FYI this issue has cropped up again here:

* https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1393