I'm not sure I understand the concern. When compiling a large project for -m32 vs. -m64, there must be a million times the compiler has to decide whether to emit "r" or "e" before a register name. HJ's patch already does this for the thunk symbol. What is the future requirement that I am not understanding, and that is so hard?
Back to real computer and will stop top-posting HTML soon, I promise! On 14 Jan 2018 19:22, Uros Bizjak <ubiz...@gmail.com> wrote: On Sun, Jan 14, 2018 at 6:44 PM, Woodhouse, David <d...@amazon.co.uk> wrote: > This won't make the list; I'll send a more coherent and less HTML-afflicted > version later. > > The bare 'ax' naming made it painful to instantiate the external thunks for > 32-bit and 64-bot code because we had to put the e/r back again inside the > .irp reg ax bx... code. > > We could probably have lived with that but it would be painful to change now > that Linux and Xen patches with the current ABI are all lined up. I > appreciate they weren't in GCC yet so we get little sympathy but these are > strange times and we had to move fast. > > I'd really like *not* to change it now. Having the thunk name actually > include the name of the register it's using does seem nicer anyway... That's unfortunate... I suspect that in the future, one will need #ifdef __x86_64__ around eventual calls to thunks from c code because of this decision, since thunks for x86_64 target will have different names than thunks for x86_32 target. I don't know if the (single?) case of mixing 32 and 64 bit assembly in the highly specialized part of the kernel really warrants this decision. Future programmers will be grateful if kernel people can re-consider their choice in not-yet-release ABI. Uros. Amazon Web Services UK Limited. Registered in England and Wales with registration number 08650665 and which has its registered office at 60 Holborn Viaduct, London EC1A 2FD, United Kingdom.
