On Thu, Apr 23, 2026 at 10:45:37AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 22, 2026 at 09:04:11PM -0700, Josh Poimboeuf wrote:
> > Alternative replacement instructions awkwardly have insn->sym set to the
> > function they get patched to rather than the symbol (or rather lack
> > thereof) they belong to in the file.
> >
> > This makes it difficult to know where a given instruction actually
> > lives.
> >
> > Add a new insn_sym() helper which preserves the existing semantic of
> > insn->sym. Rename insn->sym to insn->_sym, which contains the actual
> > ELF binary symbol (or NULL, for alternative replacements) an instruction
> > lives in.
> >
> > The private insn->_sym value will be needed for a subsequent patch.
> >
>
> > +/*
> > + * Return the symbol associated with an instruction. For alternative
> > + * replacements, return the symbol of the original code being replaced
> > rather
> > + * than NULL. insn->_sym reflects the actual location in the ELF file.
> > + */
> > +static inline struct symbol *insn_sym(struct instruction *insn)
> > +{
> > + struct symbol *sym = insn->_sym;
> > +
> > + if (!sym && insn->alt_group && insn->alt_group->orig_group)
> > + sym = insn->alt_group->orig_group->first_insn->_sym;
> > +
> > + return sym;
> > +}
>
> That is a bit of a deref fest -- this does not affect performance
> negatively?
Ha, the "deref fest" only happens for alternative replacement
instructions, so presumably not?
--
Josh
