[PATCH v2 0/14] [x86] Fix 16-bit addressing modes (PR18220) and implement .code16 (PR8684)

David Woodhouse dwmw2 at infradead.org
Fri Dec 20 07:15:03 PST 2013


On Fri, 2013-12-20 at 01:58 +0000, Eric Christopher wrote:
> It's nice to be able to bisect any problems with individual code16
> instructions too, but I think it might be better to just split out the
> bugfix level patches (as you've done with 1 for example) and get all
> of those in first with the associated testcase fixups and then land
> the code16 patch as a hunk if we want to minimize the rewriting you
> have to do for each patch.
> 
> 
> The maximally tested mechanism would be to split up things via command
> line option etc. I'm not sure it's worth it in this case as you say.
> 
> 
> Lot of the patches do seem like they'd have been good with incremental
> commits and tests added though :)

OK, I've sent a new series with incremental test cases, and I think with
the other review feedback addressed. Thanks.

The new submission isn't S/MIME-signed so shouldn't be QP-encoded and
you should be able to apply them directly, even if you are using legacy
tools instead of git :)

Reading back the above citation now that the daystar is up and I've
finished the pot of coffee, I realise that the one thing I *haven't*
done is split out the bug fixes and put them before the code16 patch, as
you suggested. I suppose we *could* consider the lack of pushaw, popaw,
jmpw and callw in 32-bit mode to be a bug, and push *part* of those two
patches earlier in the sequence. But the part which fixes the aliases
would have to stay where it is in the sequence though, since it uses the
In16BitMode predicate). So... prod me if you *really* want that :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- 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/20131220/328fcd7b/attachment.bin>


More information about the llvm-commits mailing list