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* <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/>*.* 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/f5e7f708/attachment.html>
Yes, it’s unexpected -- these 32 bit relocs are section relative and by using them the code generator is assuming that the two sections will be loaded within 4GB of one another. So for large code model compiles, they shouldn’t be used. From: Joshua Gerrard [mailto:joshua.gerrard at roli.com] Sent: Wednesday, October 14, 2015 12:52 AM To: Lang Hames <lhames at gmail.com> Cc: Andy Ayers <andya at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [cfe-dev] Orc Windows C++ 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<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/>. On 14 October 2015 at 06:48, Lang Hames <lhames at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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<mailto:halivingston at gmail.com>> >>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto: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<mailto: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<http://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<mailto: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<mailto: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<http://m.org>%2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy >>>>>> a%40microsoft.com<http://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<http://t.cern.ch>%2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya% >>>>>> 40microsoft.com<http://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<mailto:cfe-dev at lists.llvm.org> >>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist >>>>>> s.llvm.org<http://s.llvm.org>%2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca >>>>>> ndya%40microsoft.com<http://40microsoft.com>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86 >>>>>> f141af91ab2d7cd011db47%7c1&sdata=9uOfIMd1%2b2DesS3Bne%2f2jkbDpV5REzk >>>>>> VYj33rujvMGY%3d >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists >>>>> .llvm.org<http://llvm.org>%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can >>>>> dya%40microsoft.com<http://40microsoft.com>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f1 >>>>> 41af91ab2d7cd011db47%7c1&sdata=FZAxWxfyZeisom9maEJGCLgK2aboy%2bnneyka >>>>> 4FPlh%2bE%3d >>>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org<mailto: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<mailto: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/99c85b61/attachment-0001.html>
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>
That's great news, thanks! I'll spend as much time as possible today trying to minimise the relocation issue. -- 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/>*.* On 15 October 2015 at 00:39, Lang Hames <lhames at gmail.com> wrote:> 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* > <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/>*.* > > > 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/20151015/697b8c2b/attachment.html>
First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced inside of the COFF::IMAGE_REL_AMD64_ADDR64 case of resolveRelocation inside RuntimeDyldCOFFx86_64. I took a look at the link provided earlier and noticed a few things... - LLILC provides a resolver that simply returns UINT64_MAX for any given symbol, which the comment explains indicates means that we want to skip relocation resolution and that the client code will handle it manually. - recordRelocations is supposed to be that “manual handling” This raises the following questions: 1) Forgive the noobishness of this, but what is meant by “external” relocations? Something in a DLL? A static library? Something akin to a function declaration in C++ where the definition is not provided (similar to the linker error “unresolved external symbol” you get if you declare without defining at the link stage in many toolchains)? 2) recordRelocations is doing quite a lot! Given that having external symbols in code (assuming one of my definitions above is correct) is quite a normal thing, is there anything in LLVM that can help me implement this a bit more simply? Thank you very much for any help in advance. -- 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 15 Oct 2015, at 00:39, Lang Hames <lhames at gmail.com> wrote: > > 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 <mailto: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 <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/>. >> >> >> >> On 14 October 2015 at 06:48, Lang Hames <lhames at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto:halivingston at gmail.com>> >> >>> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto: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 <mailto:halivingston at gmail.com>> wrote: >> >>>> >> >>>> Maybe looking at their code might help: >> >>>> >> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu> >> >>>> b.com <http://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 <mailto: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 <mailto: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 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv> >> >>>>>> m.org <http://m.org/>%2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy >> >>>>>> a%40microsoft.com <http://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 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo> >> >>>>>> t.cern.ch <http://t.cern.ch/>%2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya% >> >>>>>> 40microsoft.com <http://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 <mailto:cfe-dev at lists.llvm.org> >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist> >> >>>>>> s.llvm.org <http://s.llvm.org/>%2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca >> >>>>>> ndya%40microsoft.com <http://40microsoft.com/>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86 >> >>>>>> f141af91ab2d7cd011db47%7c1&sdata=9uOfIMd1%2b2DesS3Bne%2f2jkbDpV5REzk >> >>>>>> VYj33rujvMGY%3d >> >>>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> LLVM Developers mailing list >> >>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists> >> >>>>> .llvm.org <http://llvm.org/>%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can >> >>>>> dya%40microsoft.com <http://40microsoft.com/>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f1 >> >>>>> 41af91ab2d7cd011db47%7c1&sdata=FZAxWxfyZeisom9maEJGCLgK2aboy%2bnneyka >> >>>>> 4FPlh%2bE%3d >> >>>>> >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> llvm-dev at lists.llvm.org <mailto: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 <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 <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20151019/b5e3affd/attachment-0001.html>