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

Thu Oct 15 00:51:47 PDT 2015

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>