In commit 519631a4, USE=mpx is introduced to toolchain.eclass to add support for the new Intel MPX (see bug #578396). However, we've been using CPU_FLAGS_X86 to track amd64 cpu flags. In fact, that commit even adds a description of cpu_flags_x86_mpx to profiles/desc/cpu_flags_x86.desc and does all the appropriate maskings in base/use.mask, and but just uses mpx in toolchain.eclass. We should pick one or the other flag, and not have duplicates. Preferably, we should use the USE_EXPAND flag because its global and stylistically follows how we treat all other amd64 flags.
The only reason I see for not using CPU_FLAGS_* would be if users may want to have the flag enabled independently of the CPU support. For example, app-emulation/bochs uses USE=avx to control emulating AVX instructions (!= cpu_flags_x86_avx that is for using AVX instructions from host CPU). But I don't think this applies here.
mpx means "build the libmpx runtime library", not "use mpx instructions". There is no reason to assume that just because your host CPU supports it you want to build the instrumentation library.
maybe libmpx would be a better flag name.
(In reply to Ryan Hill from comment #2) > mpx means "build the libmpx runtime library", not "use mpx instructions". > There is no reason to assume that just because your host CPU supports it you > want to build the instrumentation library. Well they're not completely independent since you can't build libmpx if your cpu doesn't support mpx instructions. This doesn't seem so different from what we do in other packages (eg vlc) where one can turn on/off code which requires certain cpu instructions for optimization (eg mmx), only in this case its instrumentation not optimization. If your cpu supports mmx and you want vlc built without it, you do "media-video/vlc -cpu_flags_x86_mmx". Similarly, if your cpu supports mpx and you want gcc built with libmpx, you do "sys-devel/gcc -cpu_flags_x86_mpx". Since I've never used mpx, what I don't know is whether there's some gcc switch that allows you to build executables with/without mpx instrumentation. I would assume there is and that its off by default. In which case I would think a sane default is build libmpx if your cpu supports it, but compile using gcc with mpx instrumentation off. Then libmpx is there if you want to use it for debugging or hardening, but you have to explicitly invoke it.
(In reply to Anthony Basile from comment #4) > Similarly, if your cpu supports mpx and you want gcc built with libmpx, you > do "sys-devel/gcc -cpu_flags_x86_mpx". > That should read "and you want gcc built without libmpx, you do ..."
(In reply to Anthony Basile from comment #4) > (In reply to Ryan Hill from comment #2) > > mpx means "build the libmpx runtime library", not "use mpx instructions". > > There is no reason to assume that just because your host CPU supports it you > > want to build the instrumentation library. > > Well they're not completely independent since you can't build libmpx if your > cpu doesn't support mpx instructions. Sure you can. You can even run binaries built with mpx instructions on systems that don't support it (though I don't know why you'd want to). :) MPX is enabled by building with -mmpx and some -f flags and linking with -lmpx. So you need libmpx enabled on both the host and the target for everything to work. cpu_flags are target flags, so I can see why it would make some sense to put it there, but it doesn't when host != target. Maybe that's rare enough that it doesn't matter much though. I'm on the fence now, so your call.
(In reply to Ryan Hill from comment #6) > (In reply to Anthony Basile from comment #4) > > (In reply to Ryan Hill from comment #2) > > > mpx means "build the libmpx runtime library", not "use mpx instructions". > > > There is no reason to assume that just because your host CPU supports it you > > > want to build the instrumentation library. > > > > Well they're not completely independent since you can't build libmpx if your > > cpu doesn't support mpx instructions. > > Sure you can. You can even run binaries built with mpx instructions on > systems that don't support it (though I don't know why you'd want to). :) I don't get that. If your assembly contains op codes that your cpu can't execute, won't it fault? Or is libmpx generated with some internal logic to detect if the cpu has mpx and just stubs out any non-executable code? Anyhow if this is the case, then I think we should leave things as is and maybe just improve the metadata.xml description for the flag which currently reads "Enable support for Intel Memory Protection Extensions (MPX)". Maybe "Enable code instrumentation based on Intel Memory Protection Extensions (MPX)". > > MPX is enabled by building with -mmpx and some -f flags and linking with > -lmpx. So you need libmpx enabled on both the host and the target for > everything to work. cpu_flags are target flags, so I can see why it would > make some sense to put it there, but it doesn't when host != target. Maybe > that's rare enough that it doesn't matter much though. I'm on the fence > now, so your call. I already mentioned the case where host != target to mgorny who brought up the this flag issue to me in IRC. I think mpx during cross compile is rare enough. Actually, I've been reading up on mpx and I wonder about its usefulness in general given that it generates some false positives and has perferance hits. For future reference: https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions Anyhow, bottom line, I think leave things as they are.
Let's ask the opposite question then: do we want cpu_flags_x86_mpx for anything? Is there a case for e.g. inline mpx assembly in packages? Do we want it auto-enabled on CPUs supporting mpx?
No I don't think so. mpx support in a package would just mean building it with the necessary compiler flags. There's performance and memory costs involved so it shouldn't be on by default.
Then I think it'd better to remove it from cpu_flags_x86 as it doesn't match the way other flags are used there.
(In reply to Michał Górny from comment #10) > Then I think it'd better to remove it from cpu_flags_x86 as it doesn't match > the way other flags are used there. Yeah sounds good to me.
commit 85af9c870835e3fa9d949506e34272c0425f437e Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Wed Jul 13 17:55:05 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Wed Jul 13 17:56:56 2016 profiles: Nuke cpu_flags_x86_mpx, #588632 Remove the mpx flag from CPU_FLAGS_X86. Since mpx has memory and performance costs, this is not a flag users expect to have automatically enabled based on CPU abilities.
