Quoting Stefan Dösinger <ste...@codeweavers.com>:
But since you have to have a new gas anyway, wouldn't it be simpler to
have
a new option for gas to instruct it to choose the opcodes that are
expected
by the win32 applications?
This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
it and prefered a function attribute to turn it on per-function.
I can see that a per-function attribute makes sense to control
performance-degrading changes like the adding of the movnop; however,
there seems to be no harm in changing the opcode selection on
translation unit scale.
If there are any tools in the GNU toolchain affected by the different
opcodes, that might make the extent of any such problem more obvious -
but I would see this as a good thing, as it basically improves test
coverage, and I would think that any such problems should be easy to
fix once known.
Moreover, an assembler option can be easily added to a gcc or libstdc++-v3
testsuite run, while adding attributes to all the functions in the
testsuites would be a herculean effort and cause all manner of merge
problems down the line.
