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

[Josh Poimboeuf]

On Thu, Jun 08, 2023 at 03:38:38PM -0700, Omar Sandoval wrote:
> Hi,
> 
> As mentioned in the commit message, the motivation for this patch is
> allowing drgn to continue to make use of ORC for kernel stack unwinding.
> 
> I want to make it clear that I don't want ORC to be stable ABI. The
> kernel is free to change the format as much as needed, I just need a way
> to detect the change. (drgn already pokes at many kernel internals and
> needs updates for most kernel versions anyways. We have a big test suite
> to catch changes we care about.)
> 
> I'm not at all married to (or proud of) this particular implementation;
> I'd be happy to use anything that lets me detect the format version in
> both cases mentioned in the commit message (ELF file or core dump +
> symbol table).
> 
> It'd be great if we could get a solution in before 6.4 is released. I
> would've reported this sooner, but I just got back from paternity leave
> last week.

Hi Omar,

Peter and I agree this seems fine in principle.  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?

-- 
Josh