Re: [RFC PATCH v2 00/17] objtool: Function validation tracing

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 24, 2025 at 11:50:25AM +0200, Alexandre Chartre wrote:
> 
> On 9/24/25 11:17, Peter Zijlstra wrote:
> > On Wed, Sep 24, 2025 at 09:36:49AM +0200, Peter Zijlstra wrote:
> > 
> > > >                        | <alternative.65c4e> alt 1/4 end
> > > >   65c4e: os_xsave+0x2e | <alternative.65c4e> alt 2/4 begin
> > > >   1c3d: .altinstr_replacement+0x1c3d | | xsaves64 0x40(%rbp)
> > > >   65c53: os_xsave+0x33 | | xor %ebx,%ebx
> > > >   65c55: os_xsave+0x35 | | test %ebx,%ebx - already visited
> > > >                        | <alternative.65c4e> alt 2/4 end
> > > >   65c4e: os_xsave+0x2e | <alternative.65c4e> alt 3/4 begin
> > > >   1c38: .altinstr_replacement+0x1c38 | | xsavec64 0x40(%rbp)
> > > >   65c53: os_xsave+0x33 | | xor %ebx,%ebx - already visited
> > > >                        | <alternative.65c4e> alt 3/4 end
> > > >   65c4e: os_xsave+0x2e | <alternative.65c4e> alt 4/4 begin
> > > >   1c33: .altinstr_replacement+0x1c33 | | xsaveopt64 0x40(%rbp)
> > > >   65c53: os_xsave+0x33 | | xor %ebx,%ebx - already visited
> > > >                        | <alternative.65c4e> alt 4/4 end
> > > >   65c4e: os_xsave+0x2e | <alternative.65c4e> alt default
> > > >   65c4e: os_xsave+0x2e | xsave64 0x40(%rbp)
> > > >   65c53: os_xsave+0x33 | xor %ebx,%ebx - already visited
> > > 
> > > I find it *very* hard to read these alternatives. If at all possible, I
> > > think something like:
> > > 
> > >     65c4e: os_xsave+0x2e | xsave64	| xsaveopt64	| xsavec64	| xsaves64
> > >     65c53: os_xsave+0x33 | xor %ebx,%ebx
> > > 
> > > Would be *much* easier to follow
> > 
> > Another option is to write it source-like:
> > 
> >    65c4e: os_xsave+0x2e | ALTERNATIVE("xsave64",
> >                                       "xsaveopt64", X86_FEATURE_XSAVEOPT,
> > 				     "xsavec64", X86_FEATURE_XSAVEC,
> > 				     "xsaves64", X86_FEATURE_XSAVES);
> >    65c53: os_xsave+0x33 | xor %ebx,%ebx
> > 
> > 
> > We have the 'feature' bit, we'd just have to 'borrow' the feature
> > strings from the kernel I suppose.
> 
> Yes, that would be very useful. But I will probably look at it for a next
> set of patches.

Yes, like I said, I don't think we need to hold up the current set for
this. But given how I struggle to read that alternative stuff, I figured
we should explore alternatives :-)