It’s pretty intermittent at the moment…sometimes I get the relocation overflow
issue, sometimes I get another issue about BSS sections having no contents.
The source code to reproduce either is simple:
#include <iostream>
int main (int argc, char* argv[])
{
}
I’ve managed to reproduce the BSS section issue in clang consistently, and since
that comes before terms of where it happens in the compilation / JIT’ing
process, I can’t get to the part where I see the relocation issue in clang.exe
rather than my own program.
clang.exe -c "Y:\Documents\Visual Studio
2013\Projects\NewProject\Source\main.cpp"
llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll
It also occurs with -mcmodel=large specified.
The exact output of the second command, llvm-rtdyld, is as follows...
Assertion failed: (Sec->Characteristics &
COFF::IMAGE_SCN_CNT_UNINITIALIZED_DATA) == 0 && "BSS sections
don't have contents!", file C:\llvm\llvm\lib\Object\COFFObjectFile.cpp,
line 951
0x00007FF65EAA574C (0x0000000000000016 0x00007FFC73140648 0x0000007900000008
0x00000079E68EDC40), HandleAbort() + 0xC bytes(s),
c:\llvm\llvm\lib\support\windows\signals.inc, line 296
0x00007FFC807B396F (0x00007FF600000016 0x0000000000000000 0x0000007900000004
0x0000000000000101), raise() + 0x35F bytes(s)
0x00007FFC807C2060 (0x00000079E68EE3F0 0x0000000000000240 0x00007FFC80888430
0x00007FF65F7BFF80), abort() + 0x40 bytes(s)
0x00007FFC807ABF78 (0x00007FF65F7BFF80 0x00007FF65F7BFEF0 0xCCCCCCCC000003B7
0xCCCCCCCCCCCCCCCC), _wassert() + 0x108 bytes(s)
0x00007FF65E9E7F57 (0x00000079E6A4AC40 0x00000079E68EE998 0x00000079E6A317FC
0x00000079E68EE968), llvm::object::COFFObjectFile::getSectionContents() + 0x77
bytes(s), c:\llvm\llvm\lib\object\coffobject
file.cpp, line 951 + 0x43 byte(s)
0x00007FF65E9E46E4 (0x00000079E6A4AC40 0x00000079E68EEE88 0x00000079E6A317FC
0x00000079E68EEC98), llvm::object::COFFObjectFile::getSectionContents() + 0x74
bytes(s), c:\llvm\llvm\lib\object\coffobject
file.cpp, line 293
0x00007FF65E8B2BC5 (0x00000079E68EEC48 0x00000079E68EEE88 0x00000079E68EEC98
0x00000079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s),
c:\llvm\llvm\include\llvm\object\objectfile.h
, line 375 + 0x2D byte(s)
0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40
0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s),
c:\llvm\llvm\lib\executionengine\runtimedyld
\runtimedyld.cpp, line 186 + 0x25 byte(s)
0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40
0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s),
c:\llvm\llvm\lib\executionengine\runtimedyld\runt
imedyldcoff.cpp, line 57 + 0x14 byte(s)
0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 0x00000079E6A4AC40
0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObject() + 0x221 bytes(s),
c:\llvm\llvm\lib\executionengine\runtimedyld\runtime
dyld.cpp, line 928 + 0x2F byte(s)
0x00007FF65E6781A9 (0x00007FF65FB9AB70 0x00000079E6A45150 0x00007FF65F177408
0xCCCCCCCCCCCCCCCC), executeInput() + 0x419 bytes(s),
c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 365 + 0x1D byte(
s)
0x00007FF65E67A885 (0x00007FF600000004 0x00000079E6A45150 0x0000000000000000
0x0000000000000000), main() + 0xF5 bytes(s),
c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 687 + 0x5 byte(s)
0x00007FF65EE518CD (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), __tmainCRTStartup() + 0x19D bytes(s),
f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 626 + 0x19 byte
(s)
0x00007FF65EE519FE (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), mainCRTStartup() + 0xE bytes(s),
f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 466
0x00007FFC9C4F2D92 (0x00007FFC9C4F2D70 0x0000000000000000 0x0000000000000000
0x0000000000000000), BaseThreadInitThunk() + 0x22 bytes(s)
0x00007FFC9EE19F64 (0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000), RtlUserThreadStart() + 0x34 bytes(s)
…the stack trace of which looks semantically the same as when I have that
assertion triggered in my own program.
Relevant information:
- llvm, clang and compiler-rt revision 249038 from trunk
- built with the command (where ../llvm is the llvm source root) cmake -G
"Visual Studio 12 2013 Win64" -DLLVM_INCLUDE_EXAMPLES=OFF
-DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_DOCS=OFF -DLLVM_USE_CRT_DEBUG=MDd
-DLLVM_USE_CRT_RELEASE=MD ../llvm
- VS2013 version 12.0.40629.00 Update 5
Running the same code without llvm-rtdyld.exe (i.e. non-JIT) does so without
error.
Thanks very much for any response!
(Sorry for the slow reply, was trying to get something as minimal as possible
for you to look at)
> On 2 Oct 2015, at 19:45, Andy Ayers <andya at microsoft.com> wrote:
>
> If LLVM is generating the x64 code and you have specified a large code
model, you should not see any 32 bit relocations.
>
> So it would be interesting to determine what kind of relocation you are
seeing and where it came from.
>
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Joshua Gerrard via llvm-dev
> Sent: Friday, October 2, 2015 1:18 AM
> To: Hayden Livingston <halivingston at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] Orc Windows C++
>
> Thanks for the link!
> There’s some code there that looks extremely relevant to say the least.
>
>> On 1 Oct 2015, at 19:00, Hayden Livingston <halivingston at
gmail.com> wrote:
>>
>> Maybe looking at their code might help:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2fdotnet%2fllilc%2fblob%2fdd12743f9cdb5418f1c39b2cd756da1e8396a9
>>
22%2flib%2fJit%2fLLILCJit.cpp%23L299&data=01%7c01%7candya%40microsoft.
>> com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011d
>> b47%7c1&sdata=4LCM5dPAFSQZYdEV2jNoXbtIg79%2foS5%2bB8O2Nl3ZqT4%3d
>>
>> On Thu, Oct 1, 2015 at 10:45 AM, David Blaikie via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Moving to the LLVM Dev list & cc'ing Lang.
>>>
>>> On Thu, Oct 1, 2015 at 4:23 AM, Joshua Gerrard via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>>>
>>>> Hello folks,
>>>>
>>>> I’m developing an application that uses Orc JIT for C++, which
works
>>>> swimmingly on Mac OS X. However, the Windows version has been a
>>>> battle and a half, and it’s now at the point where I need some
assistance to progress.
>>>>
>>>> The problem I’m having is “Relocation overflow” (related:
>>>>
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv
>>>>
m.org%2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy
>>>>
a%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SnxHR5RzKhzNYFDeryATV0MSpqTcjZauHtTG2GTEazA%3d
see #8) … so I spoke to some clang developers who focussed on Windows at CppCon
last week, and they gave me the following advice:
>>>> - Use ELF
>>>> - Using this results in another issue about comdat sections,
see here:
>>>>
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo
>>>>
t.cern.ch%2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya%
>>>>
40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141a
>>>>
f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv
>>>> 3Yw%3d
>>>> - Stick with COFF, but use the large code model
>>>> - No observed difference, seems to be the case because
JITDefault
>>>> is being used in the same way as Large, which would make sense
>>>> - According to the clang developers I spoke to, Lang and Andy
>>>> might have an interest in fixing this (would seem likely, as
they’re
>>>> the two commenters on the first issue I linked), since it’s
better
>>>> to use COFF on Windows than keep trying to work around it
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks in advance!
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist
>>>>
s.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca
>>>>
ndya%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86
>>>>
f141af91ab2d7cd011db47%7c1&sdata=9uOfIMd1%2b2DesS3Bne%2f2jkbDpV5REzk
>>>> VYj33rujvMGY%3d
>>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists
>>>
.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can
>>>
dya%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f1
>>>
41af91ab2d7cd011db47%7c1&sdata=FZAxWxfyZeisom9maEJGCLgK2aboy%2bnneyka
>>> 4FPlh%2bE%3d
>>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev%0a&data=01%7c01%7candya%40microsoft.com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y93xNmwi0v4F3tMocQyu1rGo7zCnU5y3T2FLxSdSWo0%3d