LLVM libunwind bad-FDE warning for JIT frame registration with newer LLVM toolchains

Bug report

Bug description:

I hit the following warning while experimenting with CPython's JIT using newer
LLVM/Clang toolchains:

libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE

CPython currently documents LLVM 21 as the officially supported LLVM version for
building the JIT. The issue described here was observed with LLVM 22.1.8 and
LLVM main 564e83191cc5686429cefe69aff81c2aeb268f5a (23.0.0git), so I do not
want to present this as a request to expand the supported LLVM range. I am
opening this mainly to share the root cause and a possible small compatibility
patch, and I would appreciate maintainers taking a careful look at whether this
is appropriate for CPython.

When a JIT executor is published for GNU backtrace() unwinding, CPython builds
a small .eh_frame buffer containing a CIE, an FDE, and a zero-length
terminator. The current GNU backtrace registration path passes the start of that
buffer to __register_frame(). That matches GCC libgcc's behavior: libgcc walks
an .eh_frame section and skips from the CIE to the FDE.

LLVM libunwind 22 and 23 expose the same __register_frame() symbol, but their
implementation treats the argument as a single FDE address. If CPython passes the
start of the .eh_frame buffer, LLVM libunwind sees the CIE first and prints the
warning above.

I confirmed that passing the first FDE address avoids the warning with LLVM
libunwind 22 and 23. The same local check also showed that GCC libgcc continues
to accept the original .eh_frame section-start registration.

A possible patch could take a narrow approach:

• for Linux builds compiled with Clang major versions 22 or 23, register and
  deregister the first FDE instead of the .eh_frame section start;
• keep the allocated .eh_frame base pointer in a small registration handle so
  teardown still frees the correct allocation;
• leave all other compilers, platforms, and Clang versions on the existing code
  path;
• add a regression check that fails if the exact LLVM libunwind bad-FDE warning
  appears in the GNU backtrace unwind helper's stderr.

The version guard would be intentionally conservative. It follows the toolchain
range where I reproduced and verified the warning, and it avoids changing
behavior for LLVM 21, which remains CPython's documented JIT dependency. That
said, this would only be a compiler-version guard; it would not be a runtime probe
for the actual unwinder implementation. If maintainers prefer a
configure-time/runtime capability check, or if this should be handled in a
different layer, I am happy to rework the approach.

Validation performed:

• main bfecfcc2a860071c8e5022ac512bde94e0fb5f76 (3.16.0a0)
• Python 3.15.0b2
• LLVM 22.1.8
• LLVM main 564e83191cc5686429cefe69aff81c2aeb268f5a (23.0.0git)

In those local builds, the warning disappeared with the patch applied.

CPython versions tested on:

3.16, 3.15

Operating systems tested on:

Linux

Linked PRs

• gh-151667

Comece pelo helper de unwind do GNU backtrace, __register_frame(), e pela construção de .eh_frame descrita aqui; compare o trabalho vinculado gh-151667 com os caminhos atuais de registro e teardown. Está concluído quando os builds Linux que usam Clang 22 ou 23 evitarem exatamente o aviso bad-FDE do LLVM libunwind, enquanto os caminhos de outros compiladores e plataformas mantiverem seu comportamento existente.