Messages in this thread | | | Date | Tue, 7 Apr 2020 18:41:43 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH V2 9/9] x86/speculation: Remove all ANNOTATE_NOSPEC_ALTERNATIVE directives |
| |
On Tue, Apr 07, 2020 at 06:18:51PM +0200, Alexandre Chartre wrote: > > On 4/7/20 4:32 PM, Alexandre Chartre wrote: > > > > On 4/7/20 3:34 PM, Josh Poimboeuf wrote: > > > On Tue, Apr 07, 2020 at 03:28:37PM +0200, Peter Zijlstra wrote: > > > > Josh, we should probably have objtool verify it doesn't emit ORC entries > > > > in alternative ranges. > > > > > > Agreed, it might be as simple as checking for insn->alt_group in the > > > INSN_STACK check or in update_insn_state(). > > > > > > > We could do that only for the "objtool orc generate" command. That way > > "objtool check" would still check the alternative, but "objtool orc generate" > > will just use the first half of the alternative (like it does today with > > ANNOTATE_NOSPEC_ALTERNATIVE). We can even keep all ANNOTATE_NOSPEC_ALTERNATIVE > > but only use them for "objtool orc generate". > > > > I have checked and objtool doesn't emit ORC entries for alternative: > decode_instructions() doesn't mark such section with sec->text = true > so create_orc_sections() doesn't emit corresponding ORC entries. > > So I think we can remove the ANNOTATE_NOSPEC_ALTERNATIVE directives, > this will allow objtool to check the instructions but it still won't > emit ORC entries (same behavior as today). In the future, if ORC > eventually supports alternative we will be ready to have objtool emit > ORC entries.
I mean, we should make it warn for the case where you remove ANNOTATE_NOSPEC and it would like to generate ORC.
Also, what's the point of having objtool grok this code and then not doing anything with it?
| |