[Bug libgcc/108994] New: LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[Bug libgcc/108994] New: LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

            Bug ID: 108994
           Summary: LLVM JIT segfaults in libgcc after upgrading from gcc
                    12.2.1 to 13.0.1
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tstellar at redhat dot com
  Target Milestone: ---

On AArch64, I'm seeing some test failures when building the latest LLVM main
branch with gcc 13.0.1 installed on my system.  Downgrading to 12.2.1 allows
the test to pass.

For example, clang/test/Interpreter/global-dtor.cpp fails with this stack
trace:

#0  0x0000fffff7c5e608 in classify_object_over_fdes () from
/lib64/libgcc_s.so.1
#1  0x0000fffff7c5f130 in __deregister_frame_info_bases () from
/lib64/libgcc_s.so.1
#2  0x0000fffff7c5f930 in __deregister_frame () from /lib64/libgcc_s.so.1
#3  0x0000000001351bc0 in llvm_orc_deregisterEHFrameSectionWrapper ()
#4  0x0000000000db9f74 in
llvm::orc::SelfExecutorProcessControl::callWrapperAsync(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorProcessControl::IncomingWFRHandler, llvm::ArrayRef<char>) ()
#5  0x0000000000da0198 in
llvm::orc::ExecutorProcessControl::callWrapper(llvm::orc::ExecutorAddr,
llvm::ArrayRef<char>) ()
#6  0x0000000000dc03d4 in llvm::Error
llvm::orc::shared::WrapperFunction<llvm::orc::shared::SPSEmpty
(llvm::orc::shared::SPSTuple<llvm::orc::shared::SPSExecutorAddr,
llvm::orc::shared::SPSExecutorAddr>)>::call<llvm::orc::ExecutorProcessControl::callSPSWrapper<void
(llvm::orc::shared::SPSTuple<llvm::orc::shared::SPSExecutorAddr,
llvm::orc::shared::SPSExecutorAddr>),
llvm::orc::ExecutorAddrRange&>(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorAddrRange&)::{lambda(char const*, unsigned long)#1},
llvm::orc::shared::SPSEmpty,
llvm::orc::ExecutorAddrRange>(llvm::orc::ExecutorProcessControl::callSPSWrapper<void
(llvm::orc::shared::SPSTuple<llvm::orc::shared::SPSExecutorAddr,
llvm::orc::shared::SPSExecutorAddr>),
llvm::orc::ExecutorAddrRange&>(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorAddrRange&)::{lambda(char const*, unsigned long)#1} const&,
llvm::orc::shared::SPSEmpty&, llvm::orc::ExecutorAddrRange const&) ()
#7  0x0000000000dc0358 in
llvm::orc::EPCEHFrameRegistrar::deregisterEHFrames(llvm::orc::ExecutorAddrRange)
()
#8  0x0000000000da8170 in
llvm::orc::EHFrameRegistrationPlugin::notifyRemovingResources(llvm::orc::JITDylib&,
unsigned long) ()
#9  0x0000000000da711c in
llvm::orc::ObjectLinkingLayer::handleRemoveResources(llvm::orc::JITDylib&,
unsigned long) ()
#10 0x0000000000d7336c in
llvm::orc::ExecutionSession::removeResourceTracker(llvm::orc::ResourceTracker&)
()
#11 0x0000000000d791cc in llvm::orc::JITDylib::clear() ()
#12 0x0000000000d8582c in llvm::orc::ExecutionSession::endSession() ()
#13 0x0000000000d9b014 in llvm::orc::LLJIT::~LLJIT() ()
#14 0x0000000000d9b170 in llvm::orc::LLJIT::~LLJIT() ()
#15 0x0000000000ff07e0 in clang::IncrementalExecutor::~IncrementalExecutor() ()
#16 0x0000000000fef788 in clang::Interpreter::~Interpreter() ()
#17 0x0000000000a46010 in main ()

The crashing program is clang-repl, which is a C++ interpreter, so it's
crashing while trying to run the code, not while trying to compile it.  I'm
working on getting a better reproducer, but if you have access to an AArch64
machine you can reproduce it like this:

git clone https://github.com/llvm/llvm-project
cd llvm-project
cmake -G Ninja -B build -S llvm -DCMAKE_BUILD_TYPE=release
-DLLVM_ENABLE_PROJECTS=clang -DLLVM_BUILD_LLVM_DYLIB=ON
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang
./build/bin/clang-repl < test.cpp
ninja -C build clang-repl

------------------------------

test.cpp:

extern "C" int printf(const char *, ...);

struct D { float f = 1.0; D *m = nullptr; D(){} ~D() { printf("D[f=%f,
m=0x%llx]\n", f, reinterpret_cast<unsigned long long>(m)); }} d;
// CHECK: D[f=1.000000, m=0x0]

--------------------------------

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|LLVM JIT segfaults in       |[13 Regression] LLVM JIT
                   |libgcc after upgrading from |segfaults in libgcc after
                   |gcc 12.2.1 to 13.0.1        |upgrading from gcc 12.2.1
                   |                            |to 13.0.1
      Known to fail|                            |13.0
   Target Milestone|---                         |13.0
      Known to work|                            |12.2.1

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you supply the output of "gcc -v"?
There was a bug dealing with the unwinder which wad fixed in the last month.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #2 from Tom Stellard <tstellar at redhat dot com> ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/13/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.0.1-20230221/obj-aarch64-redhat-linux/isl-install
--enable-gnu-indirect-function --build=aarch64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230221 (Red Hat 13.0.1-0) (GCC)

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe related to :
r13-2801-g94ccaf62c378c3
r13-2870-g386ebf75f4c034

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #4 from Tom Stellard <tstellar at redhat dot com> ---
This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, so I
bisected it down to this commit:
https://github.com/llvm/llvm-project/commit/6747fc07d1aa94e22622e278e5a02ba70675ac9b

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Tom Stellard from comment #4)
> This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> so I bisected it down to this commit:
> https://github.com/llvm/llvm-project/commit/
> 6747fc07d1aa94e22622e278e5a02ba70675ac9b

can you bisect GCC instead?

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #6 from Tom Stellard <tstellar at redhat dot com> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Tom Stellard from comment #4)
> > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> > so I bisected it down to this commit:
> > https://github.com/llvm/llvm-project/commit/
> > 6747fc07d1aa94e22622e278e5a02ba70675ac9b
> 
> can you bisect GCC instead?

I can try do you have any tips for speeding up the build?

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Tom Stellard from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Tom Stellard from comment #4)
> > > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1,
> > > so I bisected it down to this commit:
> > > https://github.com/llvm/llvm-project/commit/
> > > 6747fc07d1aa94e22622e278e5a02ba70675ac9b
> > 
> > can you bisect GCC instead?
> 
> I can try do you have any tips for speeding up the build?

Maybe try before and after the revisions I mentioned first.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Plus you can use --disable-bootstrap and maybe not rebuild llvm and just set
LD_LIBRARY_PATH.

[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You can skip things not relevant to this issue by configuring with:

--disable-multilib --disable-bootstrap --enable-languages=c++,c
--disable-libcc1 --disable-libitm --disable-libvtv --disable-libgomp
--disable-libsanitizer

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd start with verification if it is really libgcc, so don't recompile the app,
just try it against GCC 12.2.1 libgcc vs. 13.0.1.  If it is libgcc, then there
are other revisions to suspect, like
r13-2706-g6e80a1d164d1f9
r13-4757-g1c118c99706001
r13-4758-g6e56633daae79f
beyond what Andrew wrote.  And, for libgcc you don't really need to rebuild the
whole thing, once you build once (perhaps with the flags Jonathan mentioned),
git reset --hard some-commit you can just cd aarch64*/libgcc; make -jN and
retry.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #11 from Tom Stellard <tstellar at redhat dot com> ---
(In reply to Jakub Jelinek from comment #10)
> I'd start with verification if it is really libgcc, so don't recompile the
> app, just try it against GCC 12.2.1 libgcc vs. 13.0.1.

I confirmed it's libgcc.  On F37, the test passes, but then if I do `dnf
upgrade --releasever 39 libgcc` the test fails.

I'll start trying to bisect.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #12 from Tom Stellard <tstellar at redhat dot com> ---
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6e80a1d164d1f9 is the first bad
commit.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-06
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
            Summary|[13 Regression] LLVM JIT    |[13 Regression] LLVM JIT
                   |segfaults in libgcc after   |segfaults in libgcc after
                   |upgrading from gcc 12.2.1   |upgrading from gcc 12.2.1
                   |to 13.0.1                   |to 13.0.1 since
                   |                            |r13-2706-g6e80a1d164d1f9

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #13 from Tom Stellard <tstellar at redhat dot com> ---
(In reply to Tom Stellard from comment #12)
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6e80a1d164d1f9 is the first
> bad commit.

This commit also causes segfaults on s390x, but during frame registration
instead of frame deregistration:

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace.
Stack dump:
0.      Program arguments: /root/dev/llvm-project/build/bin/llvm-exegesis
-mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mode=inverse_throughput
--benchmark-phase=assemble-measured-code -x86-disable-upper-sse-registers
-opcode-name=PBLENDVBrr0 -repetition-mode=loop
 #0 0x00000000016c96aa PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x00000000016c9c18 SignalHandler(int) Signals.cpp:0:0
 #2 0x000003fff20dc488 (linux-vdso64.so.1+0x488)
 #3 0x000003ff8cc0dbe0 (/lib64/libgcc_s.so.1+0xdbe0)
 #4 0x000003ff8cc0e6ce __register_frame_info_bases
(/lib64/libgcc_s.so.1+0xe6ce)
 #5 0x0000000001ca1bb0 llvm::RTDyldMemoryManager::registerEHFrames(unsigned
char*, unsigned long, unsigned long)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1ca1bb0)
 #6 0x0000000001cb1158 llvm::RuntimeDyldELF::registerEHFrames()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1cb1158)
 #7 0x0000000001c923b6 llvm::MCJIT::finalizeLoadedModules()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1c923b6)
 #8 0x0000000001c9367a
llvm::MCJIT::getFunctionAddress(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>> const&)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1c9367a)
 #9 0x000000000171511a
llvm::exegesis::ExecutableFunction::ExecutableFunction(std::unique_ptr<llvm::LLVMTargetMachine,
std::default_delete<llvm::LLVMTargetMachine>>,
llvm::object::OwningBinary<llvm::object::ObjectFile>&&)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x171511a)
#10 0x00000000016e7ab4
llvm::exegesis::BenchmarkRunner::getRunnableConfiguration(llvm::exegesis::BenchmarkCode
const&, unsigned int, unsigned int, llvm::exegesis::SnippetRepetitor const&)
const (/root/dev/llvm-project/build/bin/llvm-exegesis+0x16e7ab4)
#11 0x0000000001077adc llvm::exegesis::benchmarkMain()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1077adc)
#12 0x000000000107ab46 main
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x107ab46)
#13 0x000003ff8ca34872 __libc_start_call_main (/lib64/libc.so.6+0x34872)
#14 0x000003ff8ca34950 __libc_start_main@GLIBC_2.2 (/lib64/libc.so.6+0x34950)
#15 0x0000000001071efa _start
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1071efa)
FileCheck error: '<stdin>' is empty.
FileCheck command line:  /root/dev/llvm-project/build/bin/FileCheck
/root/dev/llvm-project/llvm/test/tools/llvm-exegesis/X86/inverse_throughput/inverse_throughput-PBLENDVBrr0.s

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #14 from Tom Stellard <tstellar at redhat dot com> ---
Better stack trace with line numbers as of gcc commit
288bc7b5d17511d1791899e4b2e3bf3489eb06dd.


 #0 0x00000000016c96aa PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x00000000016c9c18 SignalHandler(int) Signals.cpp:0:0
 #2 0x000003ffd36fe488 (linux-vdso64.so.1+0x488)
 #3 0x000003ff9170e848 classify_object_over_fdes
/root/dev/gcc/s390x-ibm-linux-gnu/libgcc/../.././libgcc/unwind-dw2-fde.c:719:10
 #4 0x000003ff9170f606 __register_frame_info_bases
/root/dev/gcc/s390x-ibm-linux-gnu/libgcc/../.././libgcc/unwind-dw2-fde.c:130:3
 #5 0x000003ff9170f606 __register_frame_info_bases
/root/dev/gcc/s390x-ibm-linux-gnu/libgcc/../.././libgcc/unwind-dw2-fde.c:109:1
 #6 0x0000000001ca1bb0 llvm::RTDyldMemoryManager::registerEHFrames(unsigned
char*, unsigned long, unsigned long)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1ca1bb0)
 #7 0x0000000001cb1158 llvm::RuntimeDyldELF::registerEHFrames()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1cb1158)
 #8 0x0000000001c923b6 llvm::MCJIT::finalizeLoadedModules()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1c923b6)
 #9 0x0000000001c9367a
llvm::MCJIT::getFunctionAddress(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>> const&)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1c9367a)
#10 0x000000000171511a
llvm::exegesis::ExecutableFunction::ExecutableFunction(std::unique_ptr<llvm::LLVMTargetMachine,
std::default_delete<llvm::LLVMTargetMachine>>,
llvm::object::OwningBinary<llvm::object::ObjectFile>&&)
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x171511a)
#11 0x00000000016e7ab4
llvm::exegesis::BenchmarkRunner::getRunnableConfiguration(llvm::exegesis::BenchmarkCode
const&, unsigned int, unsigned int, llvm::exegesis::SnippetRepetitor const&)
const (/root/dev/llvm-project/build/bin/llvm-exegesis+0x16e7ab4)
#12 0x0000000001077adc llvm::exegesis::benchmarkMain()
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1077adc)
#13 0x000000000107ab46 main
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x107ab46)
#14 0x000003ff91534872 __libc_start_call_main (/lib64/libc.so.6+0x34872)
#15 0x000003ff91534950 __libc_start_main@GLIBC_2.2 (/lib64/libc.so.6+0x34950)
#16 0x0000000001071efa _start
(/root/dev/llvm-project/build/bin/llvm-exegesis+0x1071efa)

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So I guess the primary question would be, are threads involved in the
reproducer or not?
All the backtraces don't include start_thread, so the crashes are from the
initial thread, but that doesn't mean other threads weren't registering or
deregistering unwind info frames concurrently.
unwind-dw2-fde.c:719 is fairly simple:
  for (; ! last_fde (ob, this_fde); this_fde = next_fde (this_fde))
where last_fde is:
static inline int
last_fde (const struct object *obj __attribute__ ((__unused__)), const fde *f)
{
#ifdef DWARF2_OBJECT_END_PTR_EXTENSION
  return f == (const fde *) obj->fde_end || f->length == 0;
#else
  return f->length == 0;
#endif
}
and next_fde is:
static inline const fde *
next_fde (const fde *f)
{
  return (const fde *) ((const char *) f + f->length + sizeof (f->length));
}
So, I guess the primary question is what the LLVM JIT is calling the function
with,
if begin is a proper chain of valid .eh_frame CIEs and FDEs and if it is
properly 0 terminated.  DWARF2_OBJECT_END_PTR_EXTENSION is Darwin only.
Also, __register_frame_info_bases requires the controlling struct object to be
preserved by the caller until it is deregistered, is that the case?  Also, does
something change
the FDEs or CIEs which have been registered before they are deregistered again?

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #16 from Tom Stellard <tstellar at redhat dot com> ---
I looked into this a little more, and I think the s390x failures may be an LLVM
bug.  It's trying to JIT an X86 ELF file on s390x, and I think maybe the layout
of the frames is different due to endianness.

I'm still not sure what's going on with the aarch64 failure, though.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #17 from Tom Stellard <tstellar at redhat dot com> ---
It looks like the issue is that the function classify_object_over_fdes()
expects there to be a zero-length fde at the end of the fde array.  It doesn't
find one so it runs over the end of the array and segfaults.  I don't know if
this assumption is wrong or if LLVM should be emitting a zero-length fde at the
end of the array.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is a fundamental assumption that the FDE/CIE chain is zero terminated, after
all, all the registration APIs (__register_frame_table,
__register_frame_info_table, __register_frame_info_table_bases) take just a
begin pointer, not a begin and end pointer nor begin + count or something
similar, nor assume there is just one FDE (after all, a FDE needs some CIE, so
there would need to be a routine that expects exactly two or something
similar).

When not using .eh_frame_hdr (which is used most of the time on glibc since end
of 2001 when I've added it and somewhat later on Solaris etc.),
crtbegin.o/crtend.o ensures this, crtbegin.o provides a label at the start of
.eh_frame and is linked first among the objects:
/* Stick a label at the beginning of the frame unwind info so we can register
   and deregister it with the exception handling library code.  */
STATIC EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
     __attribute__((section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4)))
     = { };
while crtend.o provides the zero termination:
/* Terminate the frame unwind info section with a 4byte 0 as a sentinel;
   this would be the 'length' field in a real FDE.  */
# if __INT_MAX__ == 2147483647
typedef int int32;
# elif __LONG_MAX__ == 2147483647
typedef long int32;
# elif __SHRT_MAX__ == 2147483647
typedef short int32;
# else
#  error "Missing a 4 byte integer"
# endif
STATIC EH_FRAME_SECTION_CONST int32 __FRAME_END__[]
     __attribute__ ((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__),
                     aligned(__alignof__(int32))))
     = { 0 };
and is linked last.
I believe LLVM does the same thing in compiler-rt/lib/crt/crtbegin.c and
compiler-rt/lib/crt/crtend.c .
If you readelf -wf any_binary_or_library
it should show
00330010 ZERO terminator
line (with whatever address) at the end.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

--- Comment #19 from Tom Stellard <tstellar at redhat dot com> ---
Thanks, Jakub.  It looks like this is in fact an LLVM bug.  I've posted a patch
here that fixes my test case: https://reviews.llvm.org/D146067

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
closing as moved then.