[libcxx-commits] [PATCH] D59694: [PPC64][libunwind] Fix r2 not properly restored

Nemanja Ivanovic via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Mar 22 14:31:05 PDT 2019


nemanjai added a comment.

Also, is it possible to have a test case for this? I don't actually know what `libunwind` test cases look like, but seems pertinent.



================
Comment at: libunwind/src/DwarfInstructions.hpp:238
+      // then r2 was saved and needs to be restored
+      if (R::getArch() == REGISTERS_PPC64 && returnAddress != 0 &&
+          addressSpace.get32(returnAddress)
----------------
If I follow this correctly, this will just look at the return address and look at the 4 bytes at the address (i.e. the TOC restore that the linker filled in). This seems perfectly reasonable to me but I have a couple of questions:
1. Does `get32()` account for endianness correctly?
2. Why the macro checks at all?

For 2. what I am suggesting is something like:
```
// Look for the TOC restore at the return address.
if (R::getArch() == REGISTERS_PPC64 && returnAddress != 0) {
  pint_t sp = addressSpace.get64(sp + 24);
  pint_t r2 = 0;
  switch (addressSpace.get32(returnAddress)) {
    case 0xe8410018: // ld r2,24(r1) - ELFv2
      pint_t r2 = addressSpace.get64(sp + 24);
      break;
    case 0xe8410028: // ld r2,40(r1) - ELFv1
      r2 = addressSpace.get64(sp + 40);
      break;
  }
  if (r2)
    newRegisters.setRegister(UNW_PPC64_R2, r2);
}


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59694/new/

https://reviews.llvm.org/D59694





More information about the libcxx-commits mailing list