[llvm-dev] [cfe-dev] Orc Windows C++
Joshua Gerrard via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 26 04:22:07 PDT 2015
Apologies for the slow response, hectic times over here.
We know (or at least, can predetermine) in advance what DLLs and static
libraries are needed in advance, so that's good.
This gives me some idea on where to go / what to try next.
Thanks very much for the reply! I'll be coming back to this next sprint, so
I'll let you know if it works out :)
--
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 19 October 2015 at 20:51, Andy Ayers <andya at microsoft.com> wrote:
> LLILC runs inside a very specialized runtime environment (CoreCLR) and
> that environment handles resolving references to things defined outside the
> current compilation scope (“externals”). So it may not be the best example
> of how to solve your particular problems.
>
>
>
> For windows, name resolution is done differently at link time vs load time:
>
> · During linking, there is a flat global namespace searched by the
> linker. The linker will resolve module externs to a (dll-name, entry-name)
> tuple, and build an import dependency list in the module.
>
> · During loading there is a tuple-based lookup that uses
> (dll-name, entry-name) to match imports and exports. Loading a module will
> also force loading of dependent modules.
>
>
>
> When you dynamically load an object file, these rules collide, and there
> is no well-defined behavior. Here’s one plausible way to handle relocation
> processing:
>
> · You first need to know if the reference is to a symbol defined
> in the same object. Presumably this should take precedence.
>
> o If so, you can resolve it the way LLILC does for references to .rdata
> from .text.
>
> · If not, you must somehow ensure any dependent DLLs (or I
> suppose, dependent objects) are loaded
>
> o Note dependent loading auto-magically at load time requires
> considerable care because of circularities.
>
> o This is doubly hard in the “obj” case since typically there’s no
> evidence in the obj as to which DLL might provide the export.
>
> § This is normally something the linker provides via the export libs you
> link with.
>
> § You might be able to guess at it, if there are linker pragmas embedded
> by the headers you include.
>
> o You might just know the set of dependent DLLs from your application
> context. If so you could forcibly load these DLLs at startup
>
> · Once you are confident all necessary dependencies are loaded,
> external name resolution then relies on some search heuristics to look
> through the loaded DLLs/(OBJs) for a match.
>
> o Note this might find the wrong export.
>
>
>
> Hope this helps. It would be cool to have a fairly robust “obj” loading
> path, but there are certainly challenges.
>
>
>
> *From:* Joshua Gerrard [mailto:joshua.gerrard at roli.com]
> *Sent:* Monday, October 19, 2015 6:58 AM
> *To:* Lang Hames <lhames at gmail.com>; Andy Ayers <andya at microsoft.com>;
> llvm-dev <llvm-dev at lists.llvm.org>
>
> *Subject:* Re: [llvm-dev] [cfe-dev] Orc Windows C++
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.roli.com&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HVX7KcOcyaTK1D8VUCWKBUbs7YSuDX63NbIbVJdr40o%3d>
> .
>
>
>
> 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>
> 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*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.telegraph.co.uk%2fluxury%2fdesign%2f31520%2fthe-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=r9fmchyiSaifUppMJYUg8sMRS5Hvpa9UhkJhlnVEeUo%3d>* Seaboard
> GRAND, celebrated as the “**piano of the future*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fedition.cnn.com%2f2013%2f09%2f27%2ftech%2finnovation%2fhans-zimmer-seaboard-future-piano%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pdqtkFtmdcbvn8UVkmZvslRJwQwxRXtWU7RtqkutPSQ%3d>*”,
> is now joined by the **Seaboard RISE*
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.youtube.com%2fwatch%3fv%3dfGr7VbDiRNw&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bZnrYSiyTk3kWmvrhy8r75DlYJ9wJ98IkOEzJ44YOQY%3d>
> *, “**every bit as slimline and attractive as its bigger brother*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.soundonsound.com%2fnews%3fNewsID%3d18726&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fWb6BoRyElWTWIBDT%2fAEBnw3LJYHwZsiIsKHJuM17pg%3d>*”.
> The press is hailing the Seaboard RISE as “**innovative*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.wired.co.uk%2fnews%2farchive%2f2015-09%2f10%2fseaboard-rise-digital-keyboard-launch-uk-price&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nUgch6%2fObqEcKhTHSkicK%2f0d1Fhvi2Dn6sjCg%2bX%2fiyg%3d>*”,
> “**expressive*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcreatedigitalmusic.com%2f2015%2f09%2fnew-roli-instrument-wants-make-expressive-control-mainstream%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pvh2aRi9OyTBuqW3fMkMVFXTA1MH8rQTASHxkwVHnN0%3d>*”,
> “**accessible*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcreatedigitalmusic.com%2f2015%2f09%2fnew-roli-instrument-wants-make-expressive-control-mainstream%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pvh2aRi9OyTBuqW3fMkMVFXTA1MH8rQTASHxkwVHnN0%3d>*”,
> and “**a keyboard controller that does to piano keys what 3D touch does
> to the iPhone*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.slashgear.com%2froli-seaboard-rise-is-like-3d-touch-for-musicians-11404216%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zZJOuMj8pA6C%2bUjKZxfa1%2fur8bKBIrSHRMEZo4BQqUg%3d>*”.
> Now available for preorder at **www.roli.com*
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.roli.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ScPuAdcKGntB1kfZCpcVzLYSjGE5SRXbmshcD69ZICU%3d>
> *.*
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fb.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7ybIUWxHR2x%2faVMYlhV5DSZnw1pv%2fMt6JBS9loPe3Rw%3d>
> %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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fm.org%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oBDIiLPw4O%2bqd00LKx4gvde7qQoC9D0p5HcRPiTPKLg%3d>
> %2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy
> >>>>>> a%40microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40microsoft.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KxvtcMnVMiViRp1iS0OKRV1DtjlUzvb2y51HcNKg%2b4k%3d>%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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ft.cern.ch%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ig9g2wSRy9p1iIEseUcG1%2fWQZOckpIXSx6K6uXVg4nQ%3d>
> %2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya%
> >>>>>> 40microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40microsoft.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KxvtcMnVMiViRp1iS0OKRV1DtjlUzvb2y51HcNKg%2b4k%3d>
> %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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs.llvm.org%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XIvZQLcJdgIgJyLUrHEY1DlBlWr229OyqQsCMls7Ryg%3d>
> %2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca
> >>>>>> ndya%40microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40microsoft.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KxvtcMnVMiViRp1iS0OKRV1DtjlUzvb2y51HcNKg%2b4k%3d>
> %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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.org%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kw1sLPYialnyHk0s4%2bTeJnvSTC%2b9NY4BLGPgFROjUuA%3d>
> %2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can
> >>>>> dya%40microsoft.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f40microsoft.com%2f&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KxvtcMnVMiViRp1iS0OKRV1DtjlUzvb2y51HcNKg%2b4k%3d>
> %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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7candya%40microsoft.com%7cb406b5b026aa48f8cdee08d2d88d5d1b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ReP0AUqTMU6txmbaRJxHJEqzeBuOcmq1U1fVbTMMJH8%3d>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151026/94710de9/attachment.html>
More information about the llvm-dev
mailing list