[PATCH] D54937: [mips] Fix TestDWARF32Version5Addr8AllForms test failure on MIPS hosts

Simon Atanasyan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 28 05:16:34 PST 2018


atanasyan added a comment.

In D54937#1310677 <https://reviews.llvm.org/D54937#1310677>, @dblaikie wrote:

> I'm not sure I follow this well enough (probably because I know nothing about MIPS relocation types) to be a primary reviewer - but could you explain a bit more how this came to be an issue? Which commit broke MIPS here? Is this something we need to support, or perhaps just an overly general unit test that doesn't quite need the coverage it has?


I try to fix failures on the MIPS buildbot - http://lab.llvm.org:8011/builders/llvm-mips-linux. This buildbot was switched off for a long time so it's difficult to say which commit makes it "red". Anyway the problem with the `TestDWARF32Version5Addr8AllForms` unit test looks like a bug in MIPS code.

Now `MipsAsmPrinter::EmitDebugThreadLocal` always emits a special MIPS specific TLS related relocations R_MIPS_TLS_DTPREL32 / R_MIPS_TLS_DTPREL64. Result of both these relocations is "a symbol value + 0x8000 offset". It's okay when DIEExpr makes deal with a TLS variable. In "production" code it's true because DIEExpr is used in two places: `DwarfCompileUnit::addExpr` and `DwarfCompileUnit::addAddressExpr`. The `addExpr` is TLS related. The `addAddressExpr` is unrelated to TLS, but for now is not called for MIPS  (look at TODO in the `DwarfDebug::constructCallSiteEntryDIEs`). But in unit tests DIEExpr is created in one more place - `dwarfgen::DIE::addAttribute`. When this code is compiled and executed on MIPS we get incorrect DWARF because 0x8000 offset is applied to regular (non-TLS) data.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54937





More information about the llvm-commits mailing list