Skip to content

Tags: egtvedt/libunwind

Tags

v1.5-rc1

Toggle v1.5-rc1's commit message
Bump version to 1.5-rc1

v1.4.0

Toggle v1.4.0's commit message
bump release to 1.4.0

v1.3.2

Toggle v1.3.2's commit message
bump version to v1.3.2

v1.3.1

Toggle v1.3.1's commit message
bump version to 1.3.1

v1.4-rc1

Toggle v1.4-rc1's commit message
Bump to 1.4-rc1

v1.3.0

Toggle v1.3.0's commit message
bump release to 1.3.0

v1.3-rc1

Toggle v1.3-rc1's commit message
Bump version to 1.3-rc1

v1.2.1

Toggle v1.2.1's commit message
Bump version to v1.2.1

v1.2

Toggle v1.2's commit message
Bump version to 1.2

v1.2-rc1

Toggle v1.2-rc1's commit message
ppc64: Fix serious regression (many crashes in test suite)

A recent commit added code to override the unwind location for the
TOC pointer register r2:

    unsigned int *inst = (unw_word_t*)c->dwarf.ip;
    if (*inst == (0xE8410000 + 24)) {
      // @plt call, restoring R2 from CFA+24
      c->dwarf.loc[UNW_PPC64_R2] = DWARF_LOC(c->dwarf.cfa + 24, 0);
    }

It is correct that such code is needed, since DWARF CFI does not
describe the unwind location for r2 on PowerPC.  However, this
particular bit of code has a number of issues, which are fixed
in this patch.

First of all, the location CFA+24 is correct only for the ELFv2
ABI.  In the ELFv1 ABI, the TOC location is actually CFA+40.

More problematically, attempting to read the current instruction
by just dereferencing the address in c->dwarf.ip is wrong, and
may often lead to crashes.  In particular:

- During remote unwinding, this is always wrong since we're in
  the wrong address space.  I've used the fetch32 helper from
  remote.h to use the proper access_mem under the covers.

- c->dwarf.ip may be NULL if we've reached the end-of-stack.
  I've fixed this by moving the c->dwarf.ip == 0 check down
  to after unwinding (instead of before), just like all other
  platforms do.

- Even so, c->dwarf.ip may point to some random location if
  we've gotten confused during unwinding earlier.  One likely
  cause for such confusion is that we did not find DWARF CFI
  for some earlier frame and attempted to use the stack
  backchain.  The problem is that this code currently claims
  all registers remain unchanges in such a frame, which is
  generally wrong.  In particular if the function actually
  saves and modifies r31, and this is used as frame pointer
  by a later frame, things will likely go quite wrong.  While
  it is not really possibly to completely fix this, I've at
  least marked all registers as unavailable after unwinding
  a frame via stack backchain.

Tested on powerpc64-linux and powerpc64le-linux.  The patch fixes
about a dozen test cases that were crashing before.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>