[llvm-dev] COFF::IMAGE_REL_AMD64_REL32 relocation overflow when compiling for x86_64

[Joshua Gerrard via llvm-dev]

Some time ago I posted here regarding a relocation overflow on Windows
(among other things), but the issue disappeared and so the thread got left.
I've started this new thread because a) I didn't want to necro the old one
and b) it felt like its own.
I've now encountered the issue again and am noting down all the information
I can get about it whilst it's happening.

The issues is that I am getting a relocation overflow assertion inside
RuntimeDyldCOFFX86_64.h inside the COFF::IMAGE_REL_AMD64_REL32 case.
However, the other thread left me with the impression that I shouldn't be
getting such relocation when I'm compiling for 64 bit. The only reason I
can think of for this that I'm not supposed to get 32 bit relocations in
the code I'm building rather than all the code being loaded.

The LLVM side of the call stack looks like this:

_wassert(const wchar_t * expr, const wchar_t * filename, unsigned int
lineno) Line 369 C
llvm::RuntimeDyldCOFFX86_64::resolveRelocation(const llvm::RelocationEntry
& RE, unsigned __int64 Value) Line 81 C++
llvm::RuntimeDyldImpl::resolveRelocationList(const
llvm::SmallVector<llvm::RelocationEntry,64> & Relocs, unsigned __int64
Value) Line 796 C++
llvm::RuntimeDyldImpl::resolveExternalSymbols() Line 849 C++
llvm::RuntimeDyldImpl::resolveRelocations() Line 95 C++
llvm::RuntimeDyld::resolveRelocations() Line 961 C++
llvm::orc::ObjectLinkingLayer<llvm::orc::DoNothingOnNotifyLoaded>::ConcreteLinkedObjectSet<std::shared_ptr<llvm::SectionMemoryManager>,ClangClasses::LLVMExecutionEngine::LinkingResolver
* __ptr64>::Finalize() Line 112 C++
llvm::orc::ObjectLinkingLayer<llvm::orc::DoNothingOnNotifyLoaded>::findSymbolIn::__l19::<lambda>()
Line 246 C++
std::_Callable_obj<unsigned __int64 <lambda>(void),0>::_ApplyX<unsigned
__int64>() Line 284 C++
std::_Func_impl<std::_Callable_obj<unsigned __int64
<lambda>(void),0>,std::allocator<std::_Func_class<unsigned __int64>
>,unsigned __int64>::_Do_call() Line 229 C++
std::_Func_class<unsigned __int64>::operator()() Line 316 C++
llvm::orc::JITSymbol::getAddress() Line 62 C++


RelType is 4 (IMAGE_REL_AMD64_REL32).
Value is 139830239098107.
Addend is 0.

The symbol that is currently being resolved is _fperrraise. I did some
researching and it appears that this symbol resides in libcmtd.lib (for me
the path is C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\lib\amd64\libcmtd.lib).
The relocation type stated in that library (information gathered from
dumpbin) is REL32.

I'm not sure what other information there is for me to gather, could
somebody please help me resolve this?

Many thanks in advance!

--
Joshua Gerrard
JUCE Software Developer

*ROLI’s **award-winning*
<http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>*
Seaboard
GRAND, celebrated as the “**piano of the future*
<http://edition.cnn.com/2013/09/27/tech/innovation/hans-zimmer-seaboard-future-piano/>*”,
is now joined by the **Seaboard RISE*
<https://www.youtube.com/watch?v=fGr7VbDiRNw>*, “**every bit as slimline
and attractive as its bigger brother*
<http://www.soundonsound.com/news?NewsID=18726>*”. The press is hailing the
Seaboard RISE as “**innovative*
<http://www.wired.co.uk/news/archive/2015-09/10/seaboard-rise-digital-keyboard-launch-uk-price>*”,
“**expressive*
<http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/>*”,
“**accessible*
<http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/>*”,
and “**a keyboard controller that does to piano keys what 3D touch does to
the iPhone*
<http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/>*”.
Now available for preorder at **www.roli.com* <http://www.roli.com/>*.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151123/72ee2dda/attachment.html>