[LLD]Discard invalid "DW.ref.__gxx_personality_v0" pieces in rela.eh_frame

[MaooJian]

When the "DW.ref.__gxx_personality_v0" section is invalid, the generated relocation may overlap the FDE length. Discard such relocation entries to avoid corrupting the .eh_frame data.

Fixes #158011

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-lld-elf

@llvm/pr-subscribers-lld

Author: MaoJian (MaooJian)

Changes

When the "DW.ref.__gxx_personality_v0" section is invalid, the generated relocation may overlap the FDE length. Discard such relocation entries to avoid corrupting the .eh_frame data.

---

Full diff: https://github.com/llvm/llvm-project/pull/158590.diff

1 Files Affected:

• (modified) lld/ELF/InputSection.cpp (+27)

diff --git a/lld/ELF/InputSection.cpp b/lld/ELF/InputSection.cpp
index ea6bcc5bb272b..54396cd0515ed 100644
--- a/lld/ELF/InputSection.cpp
+++ b/lld/ELF/InputSection.cpp
@@ -491,6 +491,33 @@ void InputSection::copyRelocations(Ctx &ctx, uint8_t *buf,
     p->setSymbolAndType(ctx.in.symTab->getSymbolIndex(sym), type,
                         ctx.arg.isMips64EL);
 
+    // Discard the invalid pieces among those named "DW.ref.__gxx_personality_v0".
+    StringRef symName = sym.getName();
+    if (symName == "DW.ref.__gxx_personality_v0") {
+      if (auto *es = dyn_cast<EhInputSection>(sec)) {
+        auto it = partition_point(es->fdes, [=](EhSectionPiece p) {
+          return p.inputOff <= rel.offset;
+        });
+
+        if (it == es->fdes.begin() ||
+            it[-1].inputOff + it[-1].size <= rel.offset) {
+          it = partition_point(es->cies, [=](EhSectionPiece p) {
+            return p.inputOff <= rel.offset;
+          });
+          if (it == es->cies.begin()) {
+            // invalid piece
+            p->setSymbolAndType(0, 0, false);
+            continue;
+          }
+        }
+
+        if (it[-1].outputOff == -1) {
+          p->setSymbolAndType(0, 0, false);
+          continue;
+        }
+      }
+    }
+    
     if (sym.type == STT_SECTION) {
       // We combine multiple section symbols into only one per
       // section. This means we have to update the addend. That is

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[smithp35]

Can you confirm that this is something that you've observed in the relocations for --emit-relocs and not a problem that you've observed when writing the .eh_frame in an executable or shared-library?

When I worked on .ARM.exidx sections many years ago, we had a discussion about a similar problem with emit-relocs and the outcome was that complete emit-relocs was not that important so just don't emit the relocation section for it https://github.com/llvm/llvm-project/blob/main/lld/ELF/SyntheticSections.cpp#L4092

I mention this as there may be a better way of solving this problem. For example could we choose to not emit the relocations section for .eh_frame or construct it specially rather than trying to post-process it post-hoc.

Whatever the result of the discussion, please can you add a test?

[smithp35]

Is this limited to DW.ref.__gxx_personality_v0? Even if it is, if the underlying problem is that the pieces of the .eh_frame are optimised, but the relocations are not then why do you need to check for the particular symbol. Surely if the relocation offset doesn't exist then it would apply to all symbols.

Assuming this is specific to DW.ref.__gxx_personality_v0 then this is doing a string comparison on every relocation then checking that the section is an EhInputSection. I suggest that you reverse the order.