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

[Josh Poimboeuf]

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.

-- 
Josh