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

Josh Poimboeuf <[email protected]>
Newsgroups org.kernel.vger.linux-debuggers,org.kernel.vger.linux-kernel
Message-ID <20230609224803.275vqw345utsusah@treble>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.