[llvm-dev] [cfe-dev] Orc Windows C++

Wed Oct 14 16:39:15 PDT 2015

Hi Joshua,

I've managed to reproduce the BSS issue with MachO - I should have a fix in some time later today.

Cheers,
Lang.

Sent from my iPad

> On Oct 14, 2015, at 12:52 AM, Joshua Gerrard <joshua.gerrard at roli.com> wrote:
> 
> That's great news, thanks! If I can be of any help, let me know. :)
> I'll see if I can reduce the example for the relocation issue whilst you're at it.
> 
> Regards,
> 
> Joshua
> 
> --
> Joshua Gerrard
> JUCE Software Developer
> 
> ROLI’s award-winning Seaboard GRAND, celebrated as the “piano of the future”, is now joined by the Seaboard RISE, “every bit as slimline and attractive as its bigger brother”. The press is hailing the Seaboard RISE as “innovative”, “expressive”, “accessible”, and “a keyboard controller that does to piano keys what 3D touch does to the iPhone”. Now available for preorder at www.roli.com.
> 
> 
> 
>> On 14 October 2015 at 06:48, Lang Hames <lhames at gmail.com> wrote:
>> Hi Joshua, Andy,
>> 
>> I'm afraid I'm not familiar with COFF. Andy - is IMAGE_REL_AMD64_REL32 unexpected if you're compiling for 64-bit mode? It sounds like it from your description above.
>> 
>> I'll look in to the "BSS sections don't have contents" error tomorrow: It looks like it's happening in platform-agnostic RuntimeDyld code, so hopefully I can reproduce this on Darwin.
>> 
>> Cheers,
>> Lang.
>> 
>>> On Mon, Oct 5, 2015 at 9:28 AM, Joshua Gerrard via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> Oops, sorry for the spam.
>>> 
>>> That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5
>>> 
>>> > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote:
>>> >
>>> > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5
>>> >
>>> >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote:
>>> >>
>>> >> 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
>>> >>
>>> >
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151014/dda87614/attachment.html>