[LLD][eh_frame] Relocation overlaps with FDE length in .eh_frame

[MaooJian]

When compiling the following test case, I observed that relocations in .rela.eh_frame overwrite the length field of a Frame Description Entry (FDE) in .eh_frame. This only happens when linking with lld; using GNU ld does not produce this issue.

test1.cpp

#include <stdexcept>
#include <iostream>
int foo1(int x)
{
    try {
        if (x < 0)
            throw std::invalid_argument("std::invalid_argument");
        return 0;
    } catch (const std::invalid_argument &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

test2.cpp

#include <stdexcept>
#include <iostream>
int foo2(int x)
{
    try {
        if (x == 0)
            throw std::runtime_error("std::runtime_error");
        return x;
    } catch (const std::runtime_error &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

Build commands (with lld):

clang++ -O2 -fPIC -mcmodel=large -o ./test1.o -c ./test1.cpp
clang++ -O2 -fPIC -mcmodel=large -o ./test2.o -c ./test2.cpp
clang++ -fuse-ld=lld -rdynamic -Wl,--emit-relocs -shared -o test.so test1.o test2.o

Hex dump of .eh_frame:

0x00000d20 14000000 00000000 017a5200 01781001 .........zR..x..
0x00000d30 1c0c0708 90010000 1c000000 1c000000 ................
0x00000d40 50160000 00000000 2f000000 00000000 P......./.......

Relocation entries (readelf -rW test.so):

0000000000000d33  0000001700000018 R_X86_64_PC64          0000000000004680 DW.ref.__gxx_personality_v0 + 0

This relocation corresponds to bytes inside:

0x00000d30  1c0c0708 90010000 1c000000 1c000000
                  ^^^^^^^^^^^^^^^^^^

where 1c000000 encodes the FDE length field.

Normally, relocations should not overlap with the next entry header in .eh_frame.
This seems to be a bug in lld’s .eh_frame relocation handling.

Environment:

• clang/LLD version:
  • 15.0.4
  • 21.0.0git (https://github.com/llvm/llvm-project.git commit 8b40a09)
• GNU ld 2.41
• OS: Ubuntu 18.04.6 LTS
• Target: x86_64

[llvmbot]

@llvm/issue-subscribers-bug

Author: MaoJian (MaooJian)

When compiling the following test case, I observed that relocations in `.rela.eh_frame` overwrite the length field of a Frame Description Entry (FDE) in `.eh_frame`. This only happens when linking with **lld**; using GNU `ld` does **not** produce this issue.

test1.cpp

#include <stdexcept>
#include <iostream>
int foo1(int x)
{
    try {
        if (x < 0)
            throw std::invalid_argument("std::invalid_argument");
        return 0;
    } catch (const std::invalid_argument &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

test2.cpp

#include <stdexcept>
#include <iostream>
int foo2(int x)
{
    try {
        if (x == 0)
            throw std::runtime_error("std::runtime_error");
        return x;
    } catch (const std::runtime_error &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

Build commands (with lld):

clang++ -O2 -fPIC -mcmodel=large -o ./test1.o -c ./test1.cpp
clang++ -O2 -fPIC -mcmodel=large -o ./test2.o -c ./test2.cpp
clang++ -fuse-ld=lld -rdynamic -Wl,--emit-relocs -shared -o test.so test1.o test2.o

Hex dump of .eh_frame:

0x00000d20 14000000 00000000 017a5200 01781001 .........zR..x..
0x00000d30 1c0c0708 90010000 1c000000 1c000000 ................
0x00000d40 50160000 00000000 2f000000 00000000 P......./.......

Relocation entries (readelf -rW test.so):

0000000000000d33  0000001700000018 R_X86_64_PC64          0000000000004680 DW.ref.__gxx_personality_v0 + 0

This relocation corresponds to bytes inside:

0x00000d30  1c0c0708 90010000 1c000000 1c000000
                  ^^^^^^^^^^^^^^^^^^

where 1c000000 encodes the FDE length field.

Normally, relocations should not overlap with the next entry header in .eh_frame.
This seems to be a bug in lld’s .eh_frame relocation handling.

Environment:

• clang/LLD version:
  • 15.0.4
  • 21.0.0git (https://github.com/llvm/llvm-project.git commit 8b40a09)
• GNU ld 2.41
• OS: Ubuntu 18.04.6 LTS
• Target: x86_64

[hstk30-hw]

CC @MaskRay

[MaskRay]

.eh_frame CIEs and FDEs, represented as EhInputSection pieces, are optimized and ordered in a specific way, not compatible with copyRelocations. I suggest that you tool that inspects .eh_frame ignores all .rela.eh_frame relocations. #158590 that hard codes the special personality symbol, is not an acceptable approach.

[llvmbot]

@llvm/issue-subscribers-lld-elf

Author: MaoJian (MaooJian)

When compiling the following test case, I observed that relocations in `.rela.eh_frame` overwrite the length field of a Frame Description Entry (FDE) in `.eh_frame`. This only happens when linking with **lld**; using GNU `ld` does **not** produce this issue.

test1.cpp

#include <stdexcept>
#include <iostream>
int foo1(int x)
{
    try {
        if (x < 0)
            throw std::invalid_argument("std::invalid_argument");
        return 0;
    } catch (const std::invalid_argument &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

test2.cpp

#include <stdexcept>
#include <iostream>
int foo2(int x)
{
    try {
        if (x == 0)
            throw std::runtime_error("std::runtime_error");
        return x;
    } catch (const std::runtime_error &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return -1;
    }
}

Build commands (with lld):

clang++ -O2 -fPIC -mcmodel=large -o ./test1.o -c ./test1.cpp
clang++ -O2 -fPIC -mcmodel=large -o ./test2.o -c ./test2.cpp
clang++ -fuse-ld=lld -rdynamic -Wl,--emit-relocs -shared -o test.so test1.o test2.o

Hex dump of .eh_frame:

0x00000d20 14000000 00000000 017a5200 01781001 .........zR..x..
0x00000d30 1c0c0708 90010000 1c000000 1c000000 ................
0x00000d40 50160000 00000000 2f000000 00000000 P......./.......

Relocation entries (readelf -rW test.so):

0000000000000d33  0000001700000018 R_X86_64_PC64          0000000000004680 DW.ref.__gxx_personality_v0 + 0

This relocation corresponds to bytes inside:

0x00000d30  1c0c0708 90010000 1c000000 1c000000
                  ^^^^^^^^^^^^^^^^^^

where 1c000000 encodes the FDE length field.

Normally, relocations should not overlap with the next entry header in .eh_frame.
This seems to be a bug in lld’s .eh_frame relocation handling.

Environment:

• clang/LLD version:
  • 15.0.4
  • 21.0.0git (https://github.com/llvm/llvm-project.git commit 8b40a09)
• GNU ld 2.41
• OS: Ubuntu 18.04.6 LTS
• Target: x86_64

[dongjianqiang2]

.eh_frame CIEs and FDEs, represented as EhInputSection pieces, are optimized and ordered in a specific way, not compatible with copyRelocations. I suggest that you tool that inspects .eh_frame ignores all .rela.eh_frame relocations. #158590 that hard codes the special personality symbol, is not an acceptable approach.

hot patching with stack unwinding requires .eh_frame to remain consistent and reliable, since unwinding logic depends on accurate CIE/FDE entries. If relocations from .rela.eh_frame are applied incorrectly (e.g. overwriting the FDE length field), the unwind tables become corrupted, and any runtime feature that depends on precise unwinding (signal handling, exception propagation, backtraces, or hot-patch stack recovery) will fail or behave unpredictably.