LLD -Wl,-z,notext on AArch64 breaks exception handling unwind #60392

MatzeB · 2023-01-30T19:32:59Z

We see exception handling unwind failing on AArch64/Linux when using clang -fuse-ld=lld -Wl,-z,notext.

Reproducer:

extern "C" int puts(const char* str);

void __attribute__((noinline)) raise() { throw "hello!"; }

bool __attribute__((noinline)) foo() {
  try {
    raise();
  } catch (...) {
    return true;
  }
  return true;
}

int main() {
  foo();
  puts("all fine.\n");
  return 0;
}

trying this on llvm-15 or a recent git version (9470de6). Gives me:

$ build/bin/clang++ -fuse-ld=lld -Wl,-z,notext repro.cpp
$ ./a.out
terminate called after throwing an instance of 'char const*'
Aborted (core dumped)

(it should just print "all fine.")

This worked with older toolchains based on llvm-12. I bisected the problem to 4645311
/ https://reviews.llvm.org/D122459 reverting this change does fix things for me...

$ build/bin/clang++ -v
clang version 17.0.0 (ssh://git.vip.facebook.com/data/gitrepos/osmeta/external/llvm-project 9470de65bb33a18842d64ab2ab777902613ee014)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /home/matthiasb/dev/llvm-project/llvm/build/bin
Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda, version 11.8

The text was updated successfully, but these errors were encountered:

llvmbot · 2023-01-30T19:33:16Z

@llvm/issue-subscribers-backend-aarch64

llvmbot · 2023-01-30T19:33:19Z

@llvm/issue-subscribers-lld-elf

MaskRay · 2023-01-30T21:11:00Z

I cannot reproduce the failure on a Ubuntu 22.04.1 LTS AArch64 machine.

g++ 11.2.0-19ubuntu1

% ~/llvm/out/release/bin/clang++ -fuse-ld=lld a.cc -o a -Wl,-z,notext
% ./a
all fine.

% ~/llvm/out/release/bin/clang++ -fuse-ld=lld a.cc -o a -Wl,-z,notext -stdlib=libc++ -Wl,-rpath=~/llvm/out/release/lib/aarch64-unknown-linux-gnu
% ./a
all fine.

Any chance your company ships some local patches that are related?

MatzeB · 2023-01-30T21:43:14Z

I think I was only using the stock fedora server toolchain and LLVM github/main. But I'll double check and provide more details later.

MatzeB · 2023-01-31T00:04:49Z

Thanks for looking at this.

I reduced system specifics by going for LLVM libcxx/libcxxabi. It still reproduces for me (based on LLVM github/main 0534791):

$ build/bin/clang++ -v repro.cpp \
    -fuse-ld=lld \
    -stdlib=libc++ \
    --rtlib=compiler-rt \
    -Wl,-rpath=$(pwd)/build/lib/aarch64-redhat-linux-gnu \
    -Wl,-z,notext \
    --gcc-toolchain=/usr/lib/gcc/aarch64-redhat-linux/11
clang version 17.0.0 (https://github.com/llvm/llvm-project.git 053479118f18e0407f6b91304ebf19a8a735ec1f)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /home/matthiasb/dev/llvm-project/llvm/build/bin
Found CUDA installation: /usr/local/cuda, version 11.8
 "/home/matthiasb/dev/llvm-project/llvm/build/bin/clang-17" -cc1 -triple aarch64-redhat-linux-gnu -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -main-file-name repro.cpp -mrelocation-model static -mframe-pointer=non-leaf -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu generic -target-feature +neon -target-feature +v8a -target-abi aapcs -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/matthiasb/dev/llvm-project/llvm -resource-dir /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17 -internal-isystem /home/matthiasb/dev/llvm-project/llvm/build/bin/../include/aarch64-redhat-linux-gnu/c++/v1 -internal-isystem /home/matthiasb/dev/llvm-project/llvm/build/bin/../include/c++/v1 -internal-isystem /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/include -internal-isystem /usr/local/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir=/home/matthiasb/dev/llvm-project/llvm -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -target-feature +outline-atomics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/repro-fa6e11.o -x c++ repro.cpp
clang -cc1 version 17.0.0 based upon LLVM 17.0.0git default target aarch64-redhat-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/matthiasb/dev/llvm-project/llvm/build/bin/../include/aarch64-redhat-linux-gnu/c++/v1
 /home/matthiasb/dev/llvm-project/llvm/build/bin/../include/c++/v1
 /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/include
 /usr/local/include
 /usr/include
End of search list.
 "/home/matthiasb/dev/llvm-project/llvm/build/bin/ld.lld" -EL --hash-style=gnu --eh-frame-hdr -m aarch64linux -dynamic-linker /lib/ld-linux-aarch64.so.1 -o a.out /lib/../lib64/crt1.o /lib/../lib64/crti.o /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/lib/aarch64-redhat-linux-gnu/clang_rt.crtbegin.o -L/home/matthiasb/dev/llvm-project/llvm/build/bin/../lib/aarch64-redhat-linux-gnu -L/lib/../lib64 -L/usr/lib/../lib64 -L/lib -L/usr/lib /tmp/repro-fa6e11.o -rpath=/home/matthiasb/dev/llvm-project/llvm/build/lib/aarch64-redhat-linux-gnu -z notext -lc++ -lm /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/lib/aarch64-redhat-linux-gnu/libclang_rt.builtins.a -lc /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/lib/aarch64-redhat-linux-gnu/libclang_rt.builtins.a /home/matthiasb/dev/llvm-project/llvm/build/lib/clang/17/lib/aarch64-redhat-linux-gnu/clang_rt.crtend.o /lib/../lib64/crtn.o
 
 $ ./a.out
 libc++abi: terminating due to uncaught exception of type char const*
Aborted (core dumped)

Diffing llvm-readelf --all output between a failing binary and a working one with D122459 reverted I get:

$ build/bin/llvm-readelf --all ./works > works.txt
$ build/bin/llvm-readelf --all ./fails > fails.txt
$ diff -U 1000 works.txt fails.txt > delta.diff

I've uploaded delta.diff: https://gist.github.com/MatzeB/4f99823153411d4a9a3067e05f2727df

MatzeB · 2023-01-31T00:08:54Z

$ /usr/bin/g++ --version
g++ (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/g++ -dumpmachine
aarch64-redhat-linux

MaskRay · 2023-01-31T00:21:59Z

Can you link with the environment variable LLD_REPRODUCE=/tmp/rep.tar or specify -Wl,--reproduce=/tmp/rep.tar to get a tarball and upload it? delta.diff isn't sufficient to pinpoint the issue.

MatzeB · 2023-01-31T00:26:41Z

Sure: https://reviews.llvm.org/F26307225

MatzeB · 2023-01-31T22:16:28Z

FWIW:

I noticed that Clang uses this assembly:

        .cfi_personality 0, __gxx_personality_v0

while GCC uses this pattern:

        .cfi_personality 0x9b,DW.ref.__gxx_personality_v0
...
        .hidden DW.ref.__gxx_personality_v0
        .weak   DW.ref.__gxx_personality_v0
        .section        .data.DW.ref.__gxx_personality_v0,"awG",@progbits,DW.ref.__gxx_personality_v0,comdat
        .align  3
        .type   DW.ref.__gxx_personality_v0, %object
        .size   DW.ref.__gxx_personality_v0, 8
DW.ref.__gxx_personality_v0:
        .xword  __gxx_personality_v0

If I change clang generated assembly to the GCC pattern then things start working too...

MatzeB · 2023-01-31T22:22:11Z

Hmm we build LLVM with CLANG_DEFAULT_PIE_ON_LINUX=OFF over here, that may be the difference affecting the repro. Reproduces with -fno-PIE but not with -fPIE.

MaskRay · 2023-02-01T01:52:02Z

The issue is a combination of:

lld's simple -z notext processing
https://reviews.llvm.org/D122459

The comment in D122459 is wrong ("Two code paths may reach here."). There are three code paths. The third is about a dynamic relocation (use of DW_EH_PE_absptr). Unfortunately, it's difficult to handle this case without incurring performance overhead to the lld code.

However, we can avoid the issue with the CodeGen change: https://reviews.llvm.org/D143039 ([AArch64] Unconditionally use DW_EH_PE_indirect|DW_EH_PE_pcrel personality/lsda/ttype encodings) which brings our behavior closer to GCC.

On x86-64, clang++ -fno-pic -no-pie -Wl,-z,notext -mcmodel=large -g a.cc -o a; ./a has a similar crash.
We can ask what GCC thinks about using DW_EH_PE_indirect|DW_EH_PE_pcrel for -fno-pic -mcmodel=large as well.

With DW_EH_PE_indirect|DW_EH_PE_pcrel changes, perhaps we can say -Wl,-z,notext with the old DW_EH_PE_absptr encoding isn't supported by lld.

MatzeB · 2023-02-01T18:20:54Z

Thanks for investigating! Going for the same indirect codegen as GCC sounds reasonable.

Though I hope we can at least detect the problematic relocations (non-relative relocations into eh_frame?) and have lld stop and produce an error message? (as I fear people will mix&match object files from older compiler versions with newer lld...)

MaskRay · 2023-02-03T18:28:13Z

/cherry-pick 08c915f

llvmbot · 2023-02-03T18:34:45Z

/branch llvm/llvm-project-release-prs/issue60392

Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136 (cherry picked from commit 08c915f)

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: #60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is necessary for small code model since "Max text segment size < 2GiB" but it is unnecessary to make `-fno-pic -mcmodel={tiny,small}` different: The scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

llvmbot · 2023-02-03T18:43:04Z

/pull-request llvm/llvm-project-release-prs#267

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: llvm/llvm-project#60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is necessary for small code model since "Max text segment size < 2GiB" but it is unnecessary to make `-fno-pic -mcmodel={tiny,small}` different: The scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: #60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is unneeded for small code model since "Max text segment size < 2GiB" but making `-fno-pic -mcmodel={tiny,small}` different seems unnecessary: the scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) --- Two clang/test/Interpreter tests would fail without 6747fc0 ([ORC] Use JITLink as the default linker for LLJIT on Linux/arm64.) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: llvm/llvm-project#60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is unneeded for small code model since "Max text segment size < 2GiB" but making `-fno-pic -mcmodel={tiny,small}` different seems unnecessary: the scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) --- Two clang/test/Interpreter tests would fail without 6747fc07d1aa94e22622e278e5a02ba70675ac9b ([ORC] Use JITLink as the default linker for LLJIT on Linux/arm64.) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136 (cherry picked from commit 08c915f)

llvmbot · 2023-02-06T18:51:06Z

@llvm/issue-subscribers-lld-elf

Fix llvm/llvm-project#60392 ``` // a.cc void raise() { throw 42; } bool foo() { try { raise(); } catch (int) { return true; } return false; } int main() { foo(); } ``` ``` clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a ``` Both commands fail because we produce a dynamic relocation for R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong offset by `SectionBase::getOffset` after D122459. Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for .eh_frame, we follow suit as well to avoid the issue. Mips has an ABI issue (llvm/llvm-project#5837) and we don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants a dynamic relocation, so keep the original behavior for EM_MIPS. Differential Revision: https://reviews.llvm.org/D143136

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: llvm/llvm-project#60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is necessary for small code model since "Max text segment size < 2GiB" but it is unnecessary to make `-fno-pic -mcmodel={tiny,small}` different: The scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

…ality/lsda/ttype encodings For -fno-pic, without DW_EH_PE_indirect, the personality routine pointer in a CIE needs an R_AARCH64_ABS64 relocation. In common configurations that `__gcc_personality_v0` is defined in a shared object, this will lead to a discouraged canonical PLT entry, or, if `ld.lld -z notext` (betwen D122459 and D143136), a dynamic R_AARCH64_ABS64 relocation with an incorrect offset: llvm/llvm-project#60392 Since GCC uses DW_EH_PE_indirect for -fno-pic code (the behavior hasn't changed since the initial port in 2012), let's follow suit by simplifying the code. ( For tiny and small code models, we use DW_EH_PE_sdata8 instead of GCC's DW_EH_PE_sdata4. This is a deliberate choice to support personality-.eh_frame offset > 2GiB. This is unneeded for small code model since "Max text segment size < 2GiB" but making `-fno-pic -mcmodel={tiny,small}` different seems unnecessary: the scenarios that uses both -fno-pic and C++ exceptions have been increasingly rare now, so there is little advantage optimizing for the little size saving with code complexity. ) --- Two clang/test/Interpreter tests would fail without 6747fc0 ([ORC] Use JITLink as the default linker for LLJIT on Linux/arm64.) Reviewed By: MatzeB Differential Revision: https://reviews.llvm.org/D143039

MatzeB added lld backend:AArch64 lld:ELF labels Jan 30, 2023

EugeneZelenko removed the lld label Jan 30, 2023

MaskRay self-assigned this Feb 1, 2023

MaskRay closed this as completed in 08c915f Feb 3, 2023

MaskRay reopened this Feb 3, 2023

MaskRay added this to the LLVM 16.0.0 Release milestone Feb 3, 2023

EugeneZelenko added the release:backport label Feb 3, 2023

llvmbot mentioned this issue Feb 3, 2023

PR for llvm/llvm-project#60392 llvm/llvm-project-release-prs#267

Merged

MaskRay mentioned this issue Feb 4, 2023

[lld] After 46453119335, internal linker error: wrote incorrect addend value 0x74C08500 instead of 0x0 for dynamic relocation R_386_32 at offset 0x4016C7 against symbol __gxx_personality_v0 #59381

Closed

CarlosAlbertoEnciso closed this as completed in SNSystems/llvm-debuginfo-analyzer@1643997 Feb 4, 2023

EugeneZelenko added llvm:codegen and removed backend:AArch64 lld:ELF labels Feb 4, 2023

MaskRay reopened this Feb 4, 2023

tstellar closed this as completed in llvm/llvm-project-release-prs#267 Feb 6, 2023

EugeneZelenko added lld:ELF and removed llvm:codegen labels Feb 6, 2023

EugeneZelenko added the release:merged label Feb 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LLD -Wl,-z,notext on AArch64 breaks exception handling unwind #60392

LLD -Wl,-z,notext on AArch64 breaks exception handling unwind #60392

MatzeB commented Jan 30, 2023 •

edited by VoltrexKeyva

Loading

llvmbot commented Jan 30, 2023

llvmbot commented Jan 30, 2023

MaskRay commented Jan 30, 2023 •

edited by VoltrexKeyva

Loading

MatzeB commented Jan 30, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023 •

edited

Loading

MaskRay commented Jan 31, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023 •

edited

Loading

MaskRay commented Feb 1, 2023 •

edited

Loading

MatzeB commented Feb 1, 2023

MaskRay commented Feb 3, 2023

llvmbot commented Feb 3, 2023

llvmbot commented Feb 3, 2023

llvmbot commented Feb 6, 2023

LLD -Wl,-z,notext on AArch64 breaks exception handling unwind #60392

LLD -Wl,-z,notext on AArch64 breaks exception handling unwind #60392

Comments

MatzeB commented Jan 30, 2023 • edited by VoltrexKeyva Loading

llvmbot commented Jan 30, 2023

llvmbot commented Jan 30, 2023

MaskRay commented Jan 30, 2023 • edited by VoltrexKeyva Loading

MatzeB commented Jan 30, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023 • edited Loading

MaskRay commented Jan 31, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023

MatzeB commented Jan 31, 2023 • edited Loading

MaskRay commented Feb 1, 2023 • edited Loading

MatzeB commented Feb 1, 2023

MaskRay commented Feb 3, 2023

llvmbot commented Feb 3, 2023

llvmbot commented Feb 3, 2023

llvmbot commented Feb 6, 2023

MatzeB commented Jan 30, 2023 •

edited by VoltrexKeyva

Loading

MaskRay commented Jan 30, 2023 •

edited by VoltrexKeyva

Loading

MatzeB commented Jan 31, 2023 •

edited

Loading

MatzeB commented Jan 31, 2023 •

edited

Loading

MaskRay commented Feb 1, 2023 •

edited

Loading