Messages in this thread | | | Subject | Re: [PATCH V2 9/9] x86/speculation: Remove all ANNOTATE_NOSPEC_ALTERNATIVE directives | From | Alexandre Chartre <> | Date | Tue, 7 Apr 2020 19:04:28 +0200 |
| |
On 4/7/20 6:41 PM, Peter Zijlstra wrote: > 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.
Okay, so check if an alternative is changing the stack and warn if it is.
alex.
> Also, what's the point of having objtool grok this code and then not > doing anything with it? >
| |