This is an archive of the discontinued LLVM Phabricator instance.

[RuntimeDyld, PowerPC] Fix check for external symbols when detecting reloction overflow
ClosedPublic

Authored by uweigand on May 22 2017, 3:57 AM.

Details

Summary

The PowerPC part of processRelocationRef currently assumes that external symbols can be identified by checking for SymType == SymbolRef::ST_Unknown. This is actually incorrect in some cases, causing relocation overflows to be mis-detected. The correct check is to test whether Value.SymbolName is null.

Fixes PR32650.

Diff Detail

Repository
rL LLVM

Event Timeline

uweigand created this revision.May 22 2017, 3:57 AM
hfinkel accepted this revision.May 22 2017, 7:30 AM

LGTM

This revision is now accepted and ready to land.May 22 2017, 7:30 AM

Also, can we have a test case for this?

uweigand updated this revision to Diff 99893.May 23 2017, 6:20 AM

Added test case. Note that it is a bit tricky to replicate the exact condition that triggers the bug in a test case. The one attached here seems to fail reliably (before the fix) across different operating system versions on Power, but it still makes a few assumptions (called out in the comments).

Note also that no MCJIT or OrcMCJIT tests were actually run on ppc64le at all -- I've had to add the platform name to the supported list in the lit.local.cfg files in those directories ...

hfinkel accepted this revision.May 23 2017, 6:53 AM

LGTM, thanks!

This revision was automatically updated to reflect the committed changes.

This seems to have broken some MCJIT test cases on big-endian ppc64 ... I'll have a look.

It seems that to identify external symbols, we need to check for *either* non-null Value.SymbolName *or* a SymType of Symbol::ST_Unknown.

The former may happen for symbols not known to the JIT at all (e.g. defined in a native library), while the latter happens for symbols known to the JIT, but defined in a different module.

I've checked in a fix as r303655 now, this fixes the regressions on my ppc64 machine.