llvm-bolt registers .eh_frames which may refer to unmapped sections

[amharc]

BOLT currently calls RTDyld->finalizeWithMemoryManagerLocking();, which is documented to do three things:

• apply relocations;
• register .eh_frames;
• update memory permissions.

The second step will ultimately call __register_frame if its present (e.g. here).

In PIC builds the personality function is encoded with indirection (DW_EH_PE_indirect) via a DW.ref.__gxx_personality_v0 symbol located in the .data section, which is not mapped to the RuntimeDyld.

For example, for the following main.cc:

int Foo() {
  throw 42;
}

int main() {
  try {
    return Foo();
  } catch (...) {
    return 0;
  }
}

compiled with clang++ main.cc -o main -fpic -Wl,-q and processed with BOLT using llvm-bolt main -o main.bolted -keep-tmp one can see that the intermediary output object file doesn't contain the .data section.

Unfortunately this means that __register_frame can read unmapped data, e.g. LLVM's libunwind will do so when trying to read the address of the personality routine and trying to handle the DW_EH_PE_indirect case there.

I think that llvm-bolt doesn't need .eh_frames to be registered in process and probably doesn't need to update memory permissions either (as it won't execute anything from the intermediary output object file in process), so probably the call to RTDyld->finalizeWithMemoryManagerLocking() should be changed to a call to RTDyld->resolveRelocations() - but I might be wrong and this may need a more careful approach, so filing this as a bug instead of just sending a patch for review.

[llvmbot]

@llvm/issue-subscribers-bolt

[maksfb]

That's a good suggestion. Thanks! Let me verify how it works.