Re: [PATCH] x86/unwind/orc: add ELF section with ORC version number

[Omar Sandoval <osandov@osandov.com>]

On Fri, Jun 09, 2023 at 03:48:03PM -0700, Josh Poimboeuf wrote:
> On Fri, Jun 09, 2023 at 03:24:38PM -0700, Omar Sandoval wrote:
> > > Though, instead of
> > > using an incrementing version, Peter had the idea to hash the struct,
> > > like:
> > > 
> > >   awk '/^struct orc_entry {$/ { p=1 } p { print } /^}/ { p=0 }' arch/x86/include/asm/orc_types.h | sha1sum
> > > 
> > > That way we don't have to remember to bump the version number, and it
> > > would be more resilient to partial backports in distros.
> > > 
> > > Would something like that work for you?
> > 
> > Any sort of unique identifier works for me. One thing that the proposed
> > hash wouldn't catch is if ORC_REG_* or ORC_TYPE_* are ever renumbered
> > (i.e., the meanings of existing values change). It also wouldn't catch
> > if something about the .orc_unwind_ip section changed. But assuming
> > changes like that would be much rarer, it could be handled manually by
> > bumping a "salt" for the hash. E.g., by adding 'BEGIN { print <SALT> }'
> > to the awk script:
> > 
> > awk 'BEGIN { print 1 } /^struct orc_entry {$/ { p=1 } p { print } /^}/ { p=0 }' arch/x86/include/asm/orc_types.h | sha1sum
> > 
> > I'll defer to you guys whether it's easier to remember to bump a version
> > everytime or only in those rare cases.
> 
> I think I'd prefer only bumping it in the rare cases, because we're
> going to end up forgetting either way ;-)
> 
> To catch REG/TYPE changes, we could forego awk and just hash the whole
> file, the only downside being that it might introduce unnecessary
> changes if we change a comment or something.  But the file changes
> rarely enough.
> 
> Or we could tweak the awk to also print ORC_{REG,TYPE}_* pretty easily.

Printing ORC_{REG,TYPE}_* should cover almost everything, and if there's
anything not covered, it can be handled manually, so that sounds good to
me. I'll draft a patch doing that.

Thanks,
Omar