Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1724391
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent |
| Date | 2017-08-31 18:20 +0200 |
| Message-ID | <ukAmd-7Ri-9@gated-at.bofh.it> (permalink) |
| References | <ukyu5-6Gt-5@gated-at.bofh.it> <ukyu5-6Gt-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Aug 31, 2017 at 7:11 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> Make the following changes:
>
> - Give alternative_io(), alternative_call(), and alternative_call_2()
> consistent interfaces. The constraints are provided by use of the
> OUTPUTS(), INPUTS(), and CLOBBERS() macros.
I really think those macro names are way too generic. Putting them in
a core header file and expecting people to never use them is wrong.
So please rename things like "OUTPUTS()" to "ASM_OUTPUTS()" or something.
Yes, it might look slightly worse in the asm expansion. And no, we
don't actually seem to have anybody using those right now, but I did
find people using both OUTPUT and INPUT in some C files, so those
names are clearly not very unique or distinct.
On the whole, I'm not entirely sure this is the right approach. I
think we should
(a) approach clang about their obvious bug (a compiler that clobbers
%rsp because we mark it as in/out is clearly buggy)
(b) ask gcc people if there's some other alternative that would work
with clang as-is rather than the "mark %rsp register as clobbered"
I couldn't actually find the %rsp trick in any docs, I assume it came
from discussions with gcc developers directly. Maybe there is
something else we could do that doesn't upset clang?
Perhaps we can mark the frame pointer as an input, for example? Inputs
also have the advantage that appending to the input list doesn't
change the argument numbering, so we don't need to worry about
numbered arguments (not that I mind the naming of arguments, but I
kind of hate having to do it as part of this series).
Hmm?
Linus
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 0/4] x86/asm: Add ASM_CALL() macro for inline asms with call instructions Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 16:20 +0200
[RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 16:20 +0200
Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-31 18:20 +0200
Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 19:30 +0200
Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 19:40 +0200
Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Ingo Molnar <mingo@kernel.org> - 2017-09-02 12:40 +0200
[RFC PATCH 2/4] x86/asm: Convert some inline asm positional operands to named operands Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 16:20 +0200
[RFC PATCH 1/4] x86/paravirt: Fix output constraint macro names Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 16:20 +0200
[RFC PATCH 4/4] x86/asm: Use ASM_CALL() macro for inline asm statements with call instructions Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 16:20 +0200
Re: [RFC PATCH 4/4] x86/asm: Use ASM_CALL() macro for inline asm statements with call instructions Peter Zijlstra <peterz@infradead.org> - 2017-08-31 17:00 +0200
Re: [RFC PATCH 4/4] x86/asm: Use ASM_CALL() macro for inline asm statements with call instructions Josh Poimboeuf <jpoimboe@redhat.com> - 2017-08-31 17:30 +0200
Re: [RFC PATCH 4/4] x86/asm: Use ASM_CALL() macro for inline asm statements with call instructions Dmitry Vyukov <dvyukov@google.com> - 2017-08-31 17:50 +0200
csiph-web