<div dir="ltr"><div>Apologies for the slow response, hectic times over here.</div><div>We know (or at least, can predetermine) in advance what DLLs and static libraries are needed in advance, so that's good.</div><div>This gives me some idea on where to go / what to try next.</div><div><br></div>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 :)<div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><p dir="ltr">--<br> Joshua Gerrard<br> JUCE Software Developer<br></p><p dir="ltr"><font size="2"><i>ROLI’s </i><a href="http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html" target="_blank"><i><font color="#1155cc">award-winning</font></i></a><i> Seaboard GRAND, celebrated as the “</i><a href="http://edition.cnn.com/2013/09/27/tech/innovation/hans-zimmer-seaboard-future-piano/" target="_blank"><i><font color="#1155cc">piano of the future</font></i></a><i>”, is now joined by the </i><a href="https://www.youtube.com/watch?v=fGr7VbDiRNw" target="_blank"><i><font color="#1155cc">Seaboard RISE</font></i></a><i>, “</i><a href="http://www.soundonsound.com/news?NewsID=18726" target="_blank"><i><font color="#1155cc">every bit as slimline and attractive as its bigger brother</font></i></a><i>”. The press is hailing the Seaboard RISE as “</i><a href="http://www.wired.co.uk/news/archive/2015-09/10/seaboard-rise-digital-keyboard-launch-uk-price" target="_blank"><i><font color="#1155cc">innovative</font></i></a><i>”, “</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><font color="#1155cc">expressive</font></i></a><i>”, “</i><a href="http://createdigitalmusic.com/2015/09/new-roli-instrument-wants-make-expressive-control-mainstream/" target="_blank"><i><font color="#1155cc">accessible</font></i></a><i>”, and “</i><a href="http://www.slashgear.com/roli-seaboard-rise-is-like-3d-touch-for-musicians-11404216/" target="_blank"><i><font color="#1155cc">a keyboard controller that does to piano keys what 3D touch does to the iPhone</font></i></a><i>”. Now available for preorder at </i><a href="http://www.roli.com/" target="_blank"><i><font color="#1155cc">www.roli.com</font></i></a><i>.</i></font><br><br></p></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 19 October 2015 at 20:51, Andy Ayers <span dir="ltr"><<a href="mailto:andya@microsoft.com" target="_blank">andya@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">For windows, name resolution is done differently at link time vs load time:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">You first need to know if the reference is to a symbol defined in the same object. Presumably this should take precedence.<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><span>o<span style="font:7.0pt "Times New Roman"">  
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If so, you can resolve it the way LLILC does for references to .rdata from .text.
<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If not, you must somehow ensure any dependent DLLs (or I suppose, dependent objects) are loaded<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><span>o<span style="font:7.0pt "Times New Roman"">  
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Note dependent loading auto-magically at load time requires considerable care because of circularities.<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><span>o<span style="font:7.0pt "Times New Roman"">  
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.
<u></u><u></u></span></p>
<p style="margin-left:1.5in">
<u></u><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d"><span>§<span style="font:7.0pt "Times New Roman""> 
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">This is normally something the linker provides via the export libs you link with.<u></u><u></u></span></p>
<p style="margin-left:1.5in">
<u></u><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d"><span>§<span style="font:7.0pt "Times New Roman""> 
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">You might be able to guess at it, if there are linker pragmas embedded by the headers you include.<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><span>o<span style="font:7.0pt "Times New Roman"">  
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">You might just know the set of dependent DLLs from your application context. If so you could forcibly load these DLLs at startup<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p>
<p style="margin-left:1.0in">
<u></u><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><span>o<span style="font:7.0pt "Times New Roman"">  
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Note this might find the wrong export.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hope this helps. It would be cool to have a fairly robust “obj” loading path, but there are certainly challenges.
<u></u><u></u></span></p>
<p class="MsoNormal"><a name="15081a852404ecc8__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Joshua Gerrard [mailto:<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>]
<br>
<b>Sent:</b> Monday, October 19, 2015 6:58 AM<br>
<b>To:</b> Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>>; Andy Ayers <<a href="mailto:andya@microsoft.com" target="_blank">andya@microsoft.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [llvm-dev] [cfe-dev] Orc Windows C++<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I took a look at the link provided earlier and noticed a few things...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- 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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- recordRelocations is supposed to be that “manual handling”<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This raises the following questions:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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)?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thank you very much for any help in advance.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">--<br>
Joshua Gerrard<br>
JUCE Software Developer<br>
<br>
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 <a href="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" target="_blank">www.roli.com</a>.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 15 Oct 2015, at 00:39, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Hi Joshua,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I've managed to reproduce the BSS issue with MachO - I should have a fix in some time later today.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Lang.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
Sent from my iPad<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Oct 14, 2015, at 12:52 AM, Joshua Gerrard <<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">That's great news, thanks! If I can be of any help, let me know. :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'll see if I can reduce the example for the relocation issue whilst you're at it.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Joshua<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">--<br>
Joshua Gerrard<br>
JUCE Software Developer<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><i><span style="font-size:10.0pt">ROLI’s </span></i><span style="font-size:10.0pt"><a href="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" target="_blank"><i><span style="color:#1155cc">award-winning</span></i></a><i> Seaboard
 GRAND, celebrated as the “</i><a href="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" target="_blank"><i><span style="color:#1155cc">piano
 of the future</span></i></a><i>”, is now joined by the </i><a href="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" target="_blank"><i><span style="color:#1155cc">Seaboard
 RISE</span></i></a><i>, “</i><a href="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" target="_blank"><i><span style="color:#1155cc">every
 bit as slimline and attractive as its bigger brother</span></i></a><i>”. The press is hailing the Seaboard RISE as “</i><a href="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" target="_blank"><i><span style="color:#1155cc">innovative</span></i></a><i>”,
 “</i><a href="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" target="_blank"><i><span style="color:#1155cc">expressive</span></i></a><i>”,
 “</i><a href="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" target="_blank"><i><span style="color:#1155cc">accessible</span></i></a><i>”,
 and “</i><a href="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" target="_blank"><i><span style="color:#1155cc">a
 keyboard controller that does to piano keys what 3D touch does to the iPhone</span></i></a><i>”. Now available for preorder at </i><a href="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" target="_blank"><i><span style="color:#1155cc">www.roli.com</span></i></a><i>.</i></span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 14 October 2015 at 06:48, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi Joshua, Andy,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm afraid I'm not familiar with COFF. Andy - is <span style="font-size:10.0pt">IMAGE_REL_AMD64_REL32 unexpected if you're compiling for 64-bit mode? It sounds like it from your description above.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">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.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Cheers,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Lang.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, Oct 5, 2015 at 9:28 AM, Joshua Gerrard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Oops, sorry for the spam.<br>
<br>
That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5<u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
> On 5 Oct 2015, at 17:26, Joshua Gerrard <<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>> wrote:<br>
><br>
> Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5<br>
><br>
>> On 5 Oct 2015, at 17:16, Joshua Gerrard <<a href="mailto:joshua.gerrard@roli.com" target="_blank">joshua.gerrard@roli.com</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> The source code to reproduce either is simple:<br>
>><br>
>> #include <iostream><br>
>><br>
>> int main (int argc, char* argv[])<br>
>> {<br>
>><br>
>> }<br>
>><br>
>> 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.<br>
>><br>
>> clang.exe -c "Y:\Documents\Visual Studio 2013\Projects\NewProject\Source\main.cpp"<br>
>> llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll<br>
>><br>
>> It also occurs with -mcmodel=large specified.<br>
>><br>
>> The exact output of the second command, llvm-rtdyld, is as follows...<br>
>><br>
>> 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<br>
>> 0x00007FF65EAA574C (0x0000000000000016 0x00007FFC73140648 0x0000007900000008 0x00000079E68EDC40), HandleAbort() + 0xC bytes(s), c:\llvm\llvm\lib\support\windows\signals.inc, line 296<br>
>> 0x00007FFC807B396F (0x00007FF600000016 0x0000000000000000 0x0000007900000004 0x0000000000000101), raise() + 0x35F bytes(s)<br>
>> 0x00007FFC807C2060 (0x00000079E68EE3F0 0x0000000000000240 0x00007FFC80888430 0x00007FF65F7BFF80), abort() + 0x40 bytes(s)<br>
>> 0x00007FFC807ABF78 (0x00007FF65F7BFF80 0x00007FF65F7BFEF0 0xCCCCCCCC000003B7 0xCCCCCCCCCCCCCCCC), _wassert() + 0x108 bytes(s)<br>
>> 0x00007FF65E9E7F57 (0x00000079E6A4AC40 0x00000079E68EE998 0x00000079E6A317FC 0x00000079E68EE968), llvm::object::COFFObjectFile::getSectionContents() + 0x77 bytes(s), c:\llvm\llvm\lib\object\coffobject<br>
>> file.cpp, line 951 + 0x43 byte(s)<br>
>> 0x00007FF65E9E46E4 (0x00000079E6A4AC40 0x00000079E68EEE88 0x00000079E6A317FC 0x00000079E68EEC98), llvm::object::COFFObjectFile::getSectionContents() + 0x74 bytes(s), c:\llvm\llvm\lib\object\coffobject<br>
>> file.cpp, line 293<br>
>> 0x00007FF65E8B2BC5 (0x00000079E68EEC48 0x00000079E68EEE88 0x00000079E68EEC98 0x00000079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s), c:\llvm\llvm\include\llvm\object\objectfile.h<br>
>> , line 375 + 0x2D byte(s)<br>
>> 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld<br>
>> \runtimedyld.cpp, line 186 + 0x25 byte(s)<br>
>> 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld\runt<br>
>> imedyldcoff.cpp, line 57 + 0x14 byte(s)<br>
>> 0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObject() + 0x221 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld\runtime<br>
>> dyld.cpp, line 928 + 0x2F byte(s)<br>
>> 0x00007FF65E6781A9 (0x00007FF65FB9AB70 0x00000079E6A45150 0x00007FF65F177408 0xCCCCCCCCCCCCCCCC), executeInput() + 0x419 bytes(s), c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 365 + 0x1D byte(<br>
>> s)<br>
>> 0x00007FF65E67A885 (0x00007FF600000004 0x00000079E6A45150 0x0000000000000000 0x0000000000000000), main() + 0xF5 bytes(s), c:\llvm\llvm\tools\llvm-rtdyld\llvm-rtdyld.cpp, line 687 + 0x5 byte(s)<br>
>> 0x00007FF65EE518CD (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), __tmainCRTStartup() + 0x19D bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 626 + 0x19 byte<br>
>> (s)<br>
>> 0x00007FF65EE519FE (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), mainCRTStartup() + 0xE bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c, line 466<br>
>> 0x00007FFC9C4F2D92 (0x00007FFC9C4F2D70 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x22 bytes(s)<br>
>> 0x00007FFC9EE19F64 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x34 bytes(s)<br>
>><br>
>> …the stack trace of which looks semantically the same as when I have that assertion triggered in my own program.<br>
>><br>
>> Relevant information:<br>
>> - llvm, clang and compiler-rt revision 249038 from trunk<br>
>> - 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<br>
>> - VS2013 version 12.0.40629.00 Update 5<br>
>><br>
>> Running the same code without llvm-rtdyld.exe (i.e. non-JIT) does so without error.<br>
>><br>
>> Thanks very much for any response!<br>
>><br>
>> (Sorry for the slow reply, was trying to get something as minimal as possible for you to look at)<br>
>><br>
>>> On 2 Oct 2015, at 19:45, Andy Ayers <<a href="mailto:andya@microsoft.com" target="_blank">andya@microsoft.com</a>> wrote:<br>
>>><br>
>>> If LLVM is generating the x64 code and you have specified a large code model, you should not see any 32 bit relocations.<br>
>>><br>
>>> So it would be interesting to determine what kind of relocation you are seeing and where it came from.<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Joshua Gerrard via llvm-dev<br>
>>> Sent: Friday, October 2, 2015 1:18 AM<br>
>>> To: Hayden Livingston <<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@gmail.com</a>><br>
>>> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>>> Subject: Re: [llvm-dev] [cfe-dev] Orc Windows C++<br>
>>><br>
>>> Thanks for the link!<br>
>>> There’s some code there that looks extremely relevant to say the least.<br>
>>><br>
>>>> On 1 Oct 2015, at 19:00, Hayden Livingston <<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Maybe looking at their code might help:<br>
>>>><br>
>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu</a><br>
>>>> <a href="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" target="_blank">
b.com</a>%2fdotnet%2fllilc%2fblob%2fdd12743f9cdb5418f1c39b2cd756da1e8396a9<br>
>>>> 22%2flib%2fJit%2fLLILCJit.cpp%23L299&data=01%7c01%7candya%40microsoft.<br>
>>>> com%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141af91ab2d7cd011d<br>
>>>> b47%7c1&sdata=4LCM5dPAFSQZYdEV2jNoXbtIg79%2foS5%2bB8O2Nl3ZqT4%3d<br>
>>>><br>
>>>> On Thu, Oct 1, 2015 at 10:45 AM, David Blaikie via llvm-dev<br>
>>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>>> Moving to the LLVM Dev list & cc'ing Lang.<br>
>>>>><br>
>>>>> On Thu, Oct 1, 2015 at 4:23 AM, Joshua Gerrard via cfe-dev<br>
>>>>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>>>><br>
>>>>>> Hello folks,<br>
>>>>>><br>
>>>>>> I’m developing an application that uses Orc JIT for C++, which works<br>
>>>>>> swimmingly on Mac OS X. However, the Windows version has been a<br>
>>>>>> battle and a half, and it’s now at the point where I need some assistance to progress.<br>
>>>>>><br>
>>>>>> The problem I’m having is “Relocation overflow” (related:<br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fllv</a><br>
>>>>>> <a href="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" target="_blank">
m.org</a>%2fbugs%2fshow_bug.cgi%3fid%3d23228%23c8%2c&data=01%7c01%7candy<br>
>>>>>> a%<a href="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" target="_blank">40microsoft.com</a>%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:<br>
>>>>>> - Use ELF<br>
>>>>>> - Using this results in another issue about comdat sections, see here:<br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2froo</a><br>
>>>>>> <a href="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" target="_blank">
t.cern.ch</a>%2fphpBB3%2fviewtopic.php%3ft%3d19808&data=01%7c01%7candya%<br>
>>>>>> <a href="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" target="_blank">
40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141a<br>
>>>>>> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv<br>
>>>>>> 3Yw%3d<br>
>>>>>> - Stick with COFF, but use the large code model<br>
>>>>>> - No observed difference, seems to be the case because JITDefault<br>
>>>>>> is being used in the same way as Large, which would make sense<br>
>>>>>> - According to the clang developers I spoke to, Lang and Andy<br>
>>>>>> might have an interest in fixing this (would seem likely, as they’re<br>
>>>>>> the two commenters on the first issue I linked), since it’s better<br>
>>>>>> to use COFF on Windows than keep trying to work around it<br>
>>>>>><br>
>>>>>> Any ideas?<br>
>>>>>><br>
>>>>>> Thanks in advance!<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> cfe-dev mailing list<br>
>>>>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flist</a><br>
>>>>>> <a href="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" target="_blank">
s.llvm.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fcfe-dev&data=01%7c01%7ca<br>
>>>>>> ndya%<a href="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" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86<br>
>>>>>> f141af91ab2d7cd011db47%7c1&sdata=9uOfIMd1%2b2DesS3Bne%2f2jkbDpV5REzk<br>
>>>>>> VYj33rujvMGY%3d<br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> LLVM Developers mailing list<br>
>>>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>>>> <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists" target="_blank">
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists</a><br>
>>>>> .<a href="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" target="_blank">llvm.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7can<br>
>>>>> dya%<a href="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" target="_blank">40microsoft.com</a>%7ce71168aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f1<br>
>>>>> 41af91ab2d7cd011db47%7c1&sdata=FZAxWxfyZeisom9maEJGCLgK2aboy%2bnneyka<br>
>>>>> 4FPlh%2bE%3d<br>
>>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="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" target="_blank">
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</a><br>
>><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><a href="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" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>