[PATCH v2 02/14] [x86] Add basic support for .code16

[David Woodhouse]

On Sun, 2014-01-05 at 23:01 +0100, Joerg Sonnenberger wrote:
> If the feature bits are not copied in one place, a bad mode is choosen.
> Not using {0,0} as invalid encoding prevents exactly that.

But when would that happen? This was already true — if you arbitrarily
set the feature bits to all zero at some random point in the code, bad
things are going to happen. You'll end up emitting 32-bit code when you
should be in 64-bit mode, for a start.

I don't see an actual code flow which would cause the feature bits to be
*zero* instead of meaningful values. Actually, let *me* give *you* a
concrete example of the type I was looking for. Take my PR18303 fix, and
"accidentally" forget to add the getAvailableFeatures() implementation
for X86 that returns STI.getFeatureBits(). Then you really *do* end up
being invoked with the feature bits set to zero. But that is a *rare*
case. What I was looking for was a *common* coding error / idiom which
would lead to similar results, which we'd actually *need* to guard
against. I just can't see one.

But seriously, I don't care. Just sort it out amongst yourselves and
I'll implement it according to whatever consensus you reach.

Or perhaps let's apply the patch as-is so we can get the rest of the
tree merged and no longer suffering conflicts every day, then you and
Craig can continue to debate the "ideal" way to do it, and I'll clean it
up when you're done :)

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140105/d333c194/attachment.bin>