All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: Philipp Rudo <prudo@redhat.com>
Cc: Omar Sandoval <osandov@osandov.com>, linux-debuggers@vger.kernel.org
Subject: Re: Unknown ORC entry type 5 on RHEL 9 kernel
Date: Fri, 05 Dec 2025 10:38:05 -0800	[thread overview]
Message-ID: <87ldjgwz8y.fsf@oracle.com> (raw)
In-Reply-To: <20251205114106.07848df1@rotkaeppchen>

Philipp Rudo <prudo@redhat.com> writes:
> Hi Stephen,
>
> thanks for letting me know. And yes that is something we need to fix in
> the kernel rather than drgn.
>
> I took a quick look and found that the change was included when
> backporting fb799447ae29 ("x86,objtool: Split UNWIND_HINT_EMPTY in two")
> for 9.6. Thing is that I'll be heading to LPC tomorrow and won't have
> time to work on it properly before that...

Thanks for taking a deeper look! No worries on timing, it's not urgent.
If you think the most likely fix will be to backport commit
b9f174c811e3a ("x86/unwind/orc: Add ELF section with ORC version
identifier"), then I believe the drgn workaround I proposed in the
Github issue [1] should work fine: once the .orc_header section is
found, drgn will detect it and use the correct hash. The only difference
being that the "true" first broken version was 5.14.0-517.el9, which
might be worth encoding in the code in case somebody ever runs drgn
against a weird unreleased version from that development period.

[1]: https://github.com/osandov/drgn/issues/578#issuecomment-3614826789

> One more hint. When you want to get the history of RHEL, it's better to
> check the centos-stream repo then the changelog. There you have the
> full git history (modulo some embargoed CVE fixes).
>
> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9

Thanks, that helps a lot!
Stephen

> Thanks
> Philipp
>
>
> On Thu, 04 Dec 2025 12:06:54 -0800
> Stephen Brennan <stephen.s.brennan@oracle.com> wrote:
>
>> Hi Philipp,
>> 
>> I wanted to let you know about an issue with drgn's stack unwinding on
>> the RHEL 9 kernel. It looks like that kernel backports some ORC changes,
>> without including a change Omar made (including an .orc_header section)
>> to help identify the ORC format version. I've included more details on
>> this drgn issue:
>> 
>> https://github.com/osandov/drgn/issues/578
>> 
>> The result is that drgn can't unwind stacks on the RHEL 9 kernel. I
>> think the best path forward would be to include the .orc_header patch:
>> b9f174c811e3a ("x86/unwind/orc: Add ELF section with ORC version identifier")
>> 
>> As it is, the RHEL 9 drgn can't unwind stacks on the RHEL 9 kernel,
>> which seems less than ideal.
>> 
>> Thanks,
>> Stephen
>> 

  reply	other threads:[~2025-12-05 18:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-04 20:06 Unknown ORC entry type 5 on RHEL 9 kernel Stephen Brennan
2025-12-05 10:41 ` Philipp Rudo
2025-12-05 18:38   ` Stephen Brennan [this message]
2025-12-17 16:11     ` Philipp Rudo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ldjgwz8y.fsf@oracle.com \
    --to=stephen.s.brennan@oracle.com \
    --cc=linux-debuggers@vger.kernel.org \
    --cc=osandov@osandov.com \
    --cc=prudo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.