* [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers
@ 2021-05-19 13:03 Vasily Gorbik
2021-05-19 13:03 ` [PATCH 1/2] compiler.h: " Vasily Gorbik
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Vasily Gorbik @ 2021-05-19 13:03 UTC (permalink / raw)
To: Peter Zijlstra, Josh Poimboeuf
Cc: Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel
Make objtool annotations arch assembler independent. Would be nice if this goes
via objtool tree. I have further patches which depend on that.
Vasily Gorbik (2):
compiler.h: Avoid using inline asm operand modifiers
instrumentation.h: Avoid using inline asm operand modifiers
include/linux/compiler.h | 22 ++++++++++++++--------
include/linux/instrumentation.h | 20 ++++++++++++--------
2 files changed, 26 insertions(+), 16 deletions(-)
--
2.25.4
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH 1/2] compiler.h: Avoid using inline asm operand modifiers 2021-05-19 13:03 [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers Vasily Gorbik @ 2021-05-19 13:03 ` Vasily Gorbik 2021-11-05 16:54 ` Josh Poimboeuf 2021-05-19 13:03 ` [PATCH 2/2] instrumentation.h: " Vasily Gorbik 2021-05-19 20:52 ` [PATCH 0/2] objtool annotations: " Josh Poimboeuf 2 siblings, 1 reply; 8+ messages in thread From: Vasily Gorbik @ 2021-05-19 13:03 UTC (permalink / raw) To: Peter Zijlstra, Josh Poimboeuf Cc: Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel The expansion of annotate_reachable/annotate_unreachable on s390 will result in a compiler error if the __COUNTER__ value is high enough. For example with "i" (154) the "%c0" operand of annotate_reachable will be expanded to -102: -102: .pushsection .discard.reachable .long -102b - . .popsection This is a quirk of the gcc backend for s390, it interprets the %c0 as a signed byte value. Avoid using operand modifiers in this case by simply converting __COUNTER__ to string, with the same result, but in an arch assembler independent way. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> --- include/linux/compiler.h | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index df5b405e6305..77047904cf70 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -115,18 +115,24 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, * The __COUNTER__ based labels are a hack to make each instance of the macros * unique, to convince GCC not to merge duplicate inline asm statements. */ -#define annotate_reachable() ({ \ - asm volatile("%c0:\n\t" \ +#define __stringify_label(n) #n + +#define __annotate_reachable(c) ({ \ + asm volatile(__stringify_label(c) ":\n\t" \ ".pushsection .discard.reachable\n\t" \ - ".long %c0b - .\n\t" \ - ".popsection\n\t" : : "i" (__COUNTER__)); \ + ".long " __stringify_label(c) "b - .\n\t" \ + ".popsection\n\t"); \ }) -#define annotate_unreachable() ({ \ - asm volatile("%c0:\n\t" \ +#define annotate_reachable() __annotate_reachable(__COUNTER__) + +#define __annotate_unreachable(c) ({ \ + asm volatile(__stringify_label(c) ":\n\t" \ ".pushsection .discard.unreachable\n\t" \ - ".long %c0b - .\n\t" \ - ".popsection\n\t" : : "i" (__COUNTER__)); \ + ".long " __stringify_label(c) "b - .\n\t" \ + ".popsection\n\t"); \ }) +#define annotate_unreachable() __annotate_unreachable(__COUNTER__) + #define ASM_UNREACHABLE \ "999:\n\t" \ ".pushsection .discard.unreachable\n\t" \ -- 2.25.4 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] compiler.h: Avoid using inline asm operand modifiers 2021-05-19 13:03 ` [PATCH 1/2] compiler.h: " Vasily Gorbik @ 2021-11-05 16:54 ` Josh Poimboeuf 2021-11-08 15:40 ` Vasily Gorbik 0 siblings, 1 reply; 8+ messages in thread From: Josh Poimboeuf @ 2021-11-05 16:54 UTC (permalink / raw) To: Vasily Gorbik Cc: Peter Zijlstra, Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel On Wed, May 19, 2021 at 03:03:08PM +0200, Vasily Gorbik wrote: > The expansion of annotate_reachable/annotate_unreachable on s390 will > result in a compiler error if the __COUNTER__ value is high enough. > For example with "i" (154) the "%c0" operand of annotate_reachable > will be expanded to -102: > > -102: > .pushsection .discard.reachable > .long -102b - . > .popsection > > This is a quirk of the gcc backend for s390, it interprets the %c0 > as a signed byte value. Avoid using operand modifiers in this case > by simply converting __COUNTER__ to string, with the same result, > but in an arch assembler independent way. > > Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Hi Vasily, This patch causes these macros to break with Clang and CONFIG_TRACE_BRANCH_PROFILING. I get a lot of warnings like arch/x86/kernel/traps.o: warning: objtool: handle_xfd_event()+0x134: unreachable instruction Without an asm input, 'volatile' is ignored for some reason and Clang feels free to move the reachable() annotation away from its intended location. I wonder if we could go back to the original approach of providing __COUNTER__ as an input to the asm, but then mask it to < 128. Does this work on s390? diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 3d5af56337bd..42935500a712 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -115,24 +115,18 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, * The __COUNTER__ based labels are a hack to make each instance of the macros * unique, to convince GCC not to merge duplicate inline asm statements. */ -#define __stringify_label(n) #n - -#define __annotate_reachable(c) ({ \ - asm volatile(__stringify_label(c) ":\n\t" \ +#define annotate_reachable() ({ \ + asm volatile("%c0:\n\t" \ ".pushsection .discard.reachable\n\t" \ - ".long " __stringify_label(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".long %c0b - .\n\t" \ + ".popsection\n\t" : : "i" (__COUNTER__ & 0x7f)); \ }) -#define annotate_reachable() __annotate_reachable(__COUNTER__) - -#define __annotate_unreachable(c) ({ \ - asm volatile(__stringify_label(c) ":\n\t" \ +#define annotate_unreachable() ({ \ + asm volatile("%c0:\n\t" \ ".pushsection .discard.unreachable\n\t" \ - ".long " __stringify_label(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".long %c0b - .\n\t" \ + ".popsection\n\t" : : "i" (__COUNTER__ & 0x7f)); \ }) -#define annotate_unreachable() __annotate_unreachable(__COUNTER__) - #define ASM_UNREACHABLE \ "999:\n\t" \ ".pushsection .discard.unreachable\n\t" \ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] compiler.h: Avoid using inline asm operand modifiers 2021-11-05 16:54 ` Josh Poimboeuf @ 2021-11-08 15:40 ` Vasily Gorbik 2021-11-08 16:50 ` Josh Poimboeuf 2021-11-10 10:39 ` David Laight 0 siblings, 2 replies; 8+ messages in thread From: Vasily Gorbik @ 2021-11-08 15:40 UTC (permalink / raw) To: Josh Poimboeuf Cc: Peter Zijlstra, Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel On Fri, Nov 05, 2021 at 09:54:18AM -0700, Josh Poimboeuf wrote: > On Wed, May 19, 2021 at 03:03:08PM +0200, Vasily Gorbik wrote: > > The expansion of annotate_reachable/annotate_unreachable on s390 will > > result in a compiler error if the __COUNTER__ value is high enough. > > For example with "i" (154) the "%c0" operand of annotate_reachable > > will be expanded to -102: > > > > -102: > > .pushsection .discard.reachable > > .long -102b - . > > .popsection > > > > This is a quirk of the gcc backend for s390, it interprets the %c0 > > as a signed byte value. Avoid using operand modifiers in this case > > by simply converting __COUNTER__ to string, with the same result, > > but in an arch assembler independent way. > > > > Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> > > This patch causes these macros to break with Clang and > CONFIG_TRACE_BRANCH_PROFILING. > > I get a lot of warnings like > > arch/x86/kernel/traps.o: warning: objtool: handle_xfd_event()+0x134: unreachable instruction > > Without an asm input, 'volatile' is ignored for some reason and Clang > feels free to move the reachable() annotation away from its intended > location. > > I wonder if we could go back to the original approach of providing > __COUNTER__ as an input to the asm, but then mask it to < 128. > > Does this work on s390? > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 3d5af56337bd..42935500a712 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -115,24 +115,18 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, > * The __COUNTER__ based labels are a hack to make each instance of the macros > * unique, to convince GCC not to merge duplicate inline asm statements. > */ > -#define __stringify_label(n) #n > - > -#define __annotate_reachable(c) ({ \ > - asm volatile(__stringify_label(c) ":\n\t" \ > +#define annotate_reachable() ({ \ > + asm volatile("%c0:\n\t" \ > ".pushsection .discard.reachable\n\t" \ > - ".long " __stringify_label(c) "b - .\n\t" \ > - ".popsection\n\t"); \ > + ".long %c0b - .\n\t" \ > + ".popsection\n\t" : : "i" (__COUNTER__ & 0x7f)); \ > }) hm, could we just add asm input back and not use it? and keep __stringify_label(c) as is? would that work as well? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] compiler.h: Avoid using inline asm operand modifiers 2021-11-08 15:40 ` Vasily Gorbik @ 2021-11-08 16:50 ` Josh Poimboeuf 2021-11-10 10:39 ` David Laight 1 sibling, 0 replies; 8+ messages in thread From: Josh Poimboeuf @ 2021-11-08 16:50 UTC (permalink / raw) To: Vasily Gorbik Cc: Peter Zijlstra, Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel On Mon, Nov 08, 2021 at 04:40:38PM +0100, Vasily Gorbik wrote: > > Does this work on s390? > > > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > > index 3d5af56337bd..42935500a712 100644 > > --- a/include/linux/compiler.h > > +++ b/include/linux/compiler.h > > @@ -115,24 +115,18 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, > > * The __COUNTER__ based labels are a hack to make each instance of the macros > > * unique, to convince GCC not to merge duplicate inline asm statements. > > */ > > -#define __stringify_label(n) #n > > - > > -#define __annotate_reachable(c) ({ \ > > - asm volatile(__stringify_label(c) ":\n\t" \ > > +#define annotate_reachable() ({ \ > > + asm volatile("%c0:\n\t" \ > > ".pushsection .discard.reachable\n\t" \ > > - ".long " __stringify_label(c) "b - .\n\t" \ > > - ".popsection\n\t"); \ > > + ".long %c0b - .\n\t" \ > > + ".popsection\n\t" : : "i" (__COUNTER__ & 0x7f)); \ > > }) > > hm, could we just add asm input back and not use it? and keep > __stringify_label(c) as is? would that work as well? Yeah, that seems to work: diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 3d5af56337bd..429dcebe2b99 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -121,7 +121,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, asm volatile(__stringify_label(c) ":\n\t" \ ".pushsection .discard.reachable\n\t" \ ".long " __stringify_label(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".popsection\n\t" : : "i" (c)); \ }) #define annotate_reachable() __annotate_reachable(__COUNTER__) @@ -129,7 +129,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, asm volatile(__stringify_label(c) ":\n\t" \ ".pushsection .discard.unreachable\n\t" \ ".long " __stringify_label(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".popsection\n\t" : : "i" (c)); \ }) #define annotate_unreachable() __annotate_unreachable(__COUNTER__) diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h index fa2cd8c63dcc..24359b4a9605 100644 --- a/include/linux/instrumentation.h +++ b/include/linux/instrumentation.h @@ -11,7 +11,7 @@ asm volatile(__stringify(c) ": nop\n\t" \ ".pushsection .discard.instr_begin\n\t" \ ".long " __stringify(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".popsection\n\t" : : "i" (c)); \ }) #define instrumentation_begin() __instrumentation_begin(__COUNTER__) @@ -50,7 +50,7 @@ asm volatile(__stringify(c) ": nop\n\t" \ ".pushsection .discard.instr_end\n\t" \ ".long " __stringify(c) "b - .\n\t" \ - ".popsection\n\t"); \ + ".popsection\n\t" : : "i" (c)); \ }) #define instrumentation_end() __instrumentation_end(__COUNTER__) #else ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH 1/2] compiler.h: Avoid using inline asm operand modifiers 2021-11-08 15:40 ` Vasily Gorbik 2021-11-08 16:50 ` Josh Poimboeuf @ 2021-11-10 10:39 ` David Laight 1 sibling, 0 replies; 8+ messages in thread From: David Laight @ 2021-11-10 10:39 UTC (permalink / raw) To: 'Vasily Gorbik', Josh Poimboeuf Cc: Peter Zijlstra, Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel From: Vasily Gorbik > Sent: 08 November 2021 15:41 > > On Fri, Nov 05, 2021 at 09:54:18AM -0700, Josh Poimboeuf wrote: > > On Wed, May 19, 2021 at 03:03:08PM +0200, Vasily Gorbik wrote: > > > The expansion of annotate_reachable/annotate_unreachable on s390 will > > > result in a compiler error if the __COUNTER__ value is high enough. ... > > I wonder if we could go back to the original approach of providing > > __COUNTER__ as an input to the asm, but then mask it to < 128. ... > > * The __COUNTER__ based labels are a hack to make each instance of the macros > > * unique, to convince GCC not to merge duplicate inline asm statements. I've used asm comments get the same effect. Annoyingly there isn't a standard comment delimiter. I think you can just use a .equ (or .set) directive (to assign a value) rather than putting a value into a 'to be discarded' section. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] instrumentation.h: Avoid using inline asm operand modifiers 2021-05-19 13:03 [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers Vasily Gorbik 2021-05-19 13:03 ` [PATCH 1/2] compiler.h: " Vasily Gorbik @ 2021-05-19 13:03 ` Vasily Gorbik 2021-05-19 20:52 ` [PATCH 0/2] objtool annotations: " Josh Poimboeuf 2 siblings, 0 replies; 8+ messages in thread From: Vasily Gorbik @ 2021-05-19 13:03 UTC (permalink / raw) To: Peter Zijlstra, Josh Poimboeuf Cc: Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel The expansion of instrumentation_begin/instrumentation_end on s390 will result in a compiler error if the __COUNTER__ value is high enough. For example with "i" (154) the "%c0" operand of annotate_reachable will be expanded to -102: -102: .pushsection .discard.instr_begin .long -102b - . .popsection This is a quirk of the gcc backend for s390, it interprets the %c0 as a signed byte value. Avoid using operand modifiers in this case by simply converting __COUNTER__ to string, with the same result, but in an arch assembler independent way. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> --- include/linux/instrumentation.h | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h index 93e2ad67fc10..fa2cd8c63dcc 100644 --- a/include/linux/instrumentation.h +++ b/include/linux/instrumentation.h @@ -4,13 +4,16 @@ #if defined(CONFIG_DEBUG_ENTRY) && defined(CONFIG_STACK_VALIDATION) +#include <linux/stringify.h> + /* Begin/end of an instrumentation safe region */ -#define instrumentation_begin() ({ \ - asm volatile("%c0: nop\n\t" \ +#define __instrumentation_begin(c) ({ \ + asm volatile(__stringify(c) ": nop\n\t" \ ".pushsection .discard.instr_begin\n\t" \ - ".long %c0b - .\n\t" \ - ".popsection\n\t" : : "i" (__COUNTER__)); \ + ".long " __stringify(c) "b - .\n\t" \ + ".popsection\n\t"); \ }) +#define instrumentation_begin() __instrumentation_begin(__COUNTER__) /* * Because instrumentation_{begin,end}() can nest, objtool validation considers @@ -43,12 +46,13 @@ * To avoid this, have _end() be a NOP instruction, this ensures it will be * part of the condition block and does not escape. */ -#define instrumentation_end() ({ \ - asm volatile("%c0: nop\n\t" \ +#define __instrumentation_end(c) ({ \ + asm volatile(__stringify(c) ": nop\n\t" \ ".pushsection .discard.instr_end\n\t" \ - ".long %c0b - .\n\t" \ - ".popsection\n\t" : : "i" (__COUNTER__)); \ + ".long " __stringify(c) "b - .\n\t" \ + ".popsection\n\t"); \ }) +#define instrumentation_end() __instrumentation_end(__COUNTER__) #else # define instrumentation_begin() do { } while(0) # define instrumentation_end() do { } while(0) -- 2.25.4 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers 2021-05-19 13:03 [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers Vasily Gorbik 2021-05-19 13:03 ` [PATCH 1/2] compiler.h: " Vasily Gorbik 2021-05-19 13:03 ` [PATCH 2/2] instrumentation.h: " Vasily Gorbik @ 2021-05-19 20:52 ` Josh Poimboeuf 2 siblings, 0 replies; 8+ messages in thread From: Josh Poimboeuf @ 2021-05-19 20:52 UTC (permalink / raw) To: Vasily Gorbik Cc: Peter Zijlstra, Ingo Molnar, Borislav Petkov, Miroslav Benes, linux-kernel On Wed, May 19, 2021 at 03:03:02PM +0200, Vasily Gorbik wrote: > Make objtool annotations arch assembler independent. Would be nice if this goes > via objtool tree. I have further patches which depend on that. > > Vasily Gorbik (2): > compiler.h: Avoid using inline asm operand modifiers > instrumentation.h: Avoid using inline asm operand modifiers > > include/linux/compiler.h | 22 ++++++++++++++-------- > include/linux/instrumentation.h | 20 ++++++++++++-------- > 2 files changed, 26 insertions(+), 16 deletions(-) Thanks Vasily, looks good to me. Running it through some testing. -- Josh ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-11-10 10:39 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-19 13:03 [PATCH 0/2] objtool annotations: Avoid using inline asm operand modifiers Vasily Gorbik 2021-05-19 13:03 ` [PATCH 1/2] compiler.h: " Vasily Gorbik 2021-11-05 16:54 ` Josh Poimboeuf 2021-11-08 15:40 ` Vasily Gorbik 2021-11-08 16:50 ` Josh Poimboeuf 2021-11-10 10:39 ` David Laight 2021-05-19 13:03 ` [PATCH 2/2] instrumentation.h: " Vasily Gorbik 2021-05-19 20:52 ` [PATCH 0/2] objtool annotations: " Josh Poimboeuf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®