thr3ads.net - llvm dev - [llvm-dev] [cfe-dev] Orc Windows C++ [Oct 2015]

If this information is useful, please help other people find it:
Share via:

Joshua Gerrard via llvm-dev

2015-Oct-05 16:28 UTC

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

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
>> 
>

Lang Hames via llvm-dev

2015-Oct-14 05:48 UTC

head link

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

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/20151013/a7239b6e/attachment.html>

Joshua Gerrard via llvm-dev

2015-Oct-14 07:52 UTC

head link

[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> 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>

Seemingly Similar Threads

Search for more possibly parallel threads

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

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

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

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

Seemingly Similar Threads