This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information

Joseph Myers <> writes:
> > Similarly if you link -mmdmx and -mno-mdmx code together you get an
> > -mmdmx output.
> But that "-mmdmx output" will run on hardware without the relevant
> feature, if there are runtime checks, I presume

As it stands there are no checks between hardware support and executables
or shared libraries. So (for what I'm calling normal usage) an executable
that includes -mmdmx output will simply crash when run on a non-mdmx
core. I am defining normal usage to be those people who don't know how
to write clever run-time checks. Since there is no way for a userland
process to inspect whether the core supports mdmx currently then there is
no way to improve on this. The introduction of HWCAP bits (specifically
for MSA but not restricted to that) allows us to do better now for my
'normal' usage case and also start to support the idea of a user doing
runtime checks on MIPS.
> (otherwise the MSA case
> would be handled by whatever handles -mmdmx rather than any new checks in
> glibc being proposed that are specific to MSA).

We could go back and define HWCAP bits for the other ASEs and perform
appropriate checks for them as well as new ASEs. It seems like a moot
point though given there has been no such dynamic linker checks for MDMX
so far and I believe there is essentially just one implementation of MDMX.
For MIPS3D I'm not sure there are any production implementations. However,
given there is generic support for up to 64 HWCAP bits then assigning one
to each of the pre-existing ASEs won't steal too many of those bits.

To support the scenario that you pointed me towards (x86_64 multiarch I
believe it was) then the only difference for MIPS vs x86_64 would be that
the source wrappers, which are used to rename functions and define special
sections, would also need to have a pragma or other source level directive
to enable MSA for the remaining functions in the file. This allows us to
differentiate between the 'globally enable a feature' via command line
and 'hide the usage of the feature' for user-supplied runtime checks.

The thing which MIPS has and many(/all?) other architectures lack is
information stored in an executable or DSO which accurately states their
requirements. This is the basis for suggestion we should do whole
executable and whole DSO checks for MIPS (as well as supporting the user
supplied runtime detection case).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]