This is an archive of the discontinued LLVM Phabricator instance.

[mips] Fix TestDWARF32Version5Addr8AllForms test failure on MIPS hosts
ClosedPublic

Authored by atanasyan on Nov 27 2018, 1:55 AM.

Details

Summary

The DIEExpr is used in debug information entries for either TLS variables or call sites. For now the last case is unsupported for targets with delay slots, for MIPS in particular.

The DIEExpr::EmitValue method calls a virtual EmitDebugValue routine which, in case of MIPS, always emits either .dtprelword or .dtpreldword directives. That is okay for "main" code, but in unit tests DIEExpr instances can be created not for TLS variables only even on MIPS hosts. That is a reason of the TestDWARF32Version5Addr8AllForms failure because handling of the R_MIPS_TLS_DTPREL relocation writes incorrect value into dwarf structures. And anyway unconditional emitting of .dtprelword directives will be incorrect when/if debug information entries for call sites become supported on MIPS.

The patch solves the problem by wrapping expression created in the MipsTargetObjectFile::getDebugThreadLocalSymbol method in to the MipsMCExpr expression with a new MEK_DTPREL tag. This tag is recognized in the MipsAsmPrinter::EmitDebugValue method and .dtprelword directives created in this case only. In other cases the expression saved as a regular data.

Diff Detail

Repository
rL LLVM

Event Timeline

atanasyan created this revision.Nov 27 2018, 1:55 AM

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'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.

atanasyan updated this revision to Diff 175676.Nov 28 2018, 6:09 AM
atanasyan edited the summary of this revision. (Show Details)
  • Rebased against the trunk
dblaikie accepted this revision.Dec 3 2018, 11:26 AM

Fair enough - thanks!

This revision is now accepted and ready to land.Dec 3 2018, 11:26 AM

Thanks for review.

This revision was automatically updated to reflect the committed changes.