<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I don’t think this is actually a TLS-specific problem. The TLS case just exposed a couple of other shortcomings in the current code base.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The problem is two-fold. First, MCJIT doesn’t support the PIC relocation model for most platforms. Second, the MC code generation doesn’t work with large
code model and the static relocation model.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Because of these two issues, to try to get TLS working, we wanted to generate code with the static relocation model and the small code model. It’s the small
code model that requires code to be loaded in the lower 2GB. In particular, when you use small code model with static relocation model MC generates relocations that assume 32-bit addresses (R_X86_64_32). Once this relocation is generated, the RuntimeDyld
doesn’t have enough information to be able to fake it if the address it needs to write into the relocation is bigger than 32-bits.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">For PC-relative relocations, we can just rely on everything being loaded in proximity, and in fact that happens even with the large memory model. For “absolute”
32-bit relocations that doesn’t work.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Reid Kleckner [mailto:rnk@google.com]
<br>
<b>Sent:</b> Wednesday, May 15, 2013 5:47 AM<br>
<b>To:</b> Kaylor, Andrew<br>
<b>Cc:</b> David Chisnall; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] TLS with MCJIT (an experimental patch)<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Can you elaborate on why MCJIT TLS support needs code in the low 2 GB? What piece of data do you need to be reachable? It sounds like this was discussed on IRC, but I'm curious.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Does the MCJIT even have the reachability problems of the old JIT? If you build an object file in memory, presumably you can measure it and then allocate +x memory for it all at once, instead of the old model of not knowing how big it
was going to be.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we build a module at a time, presumably separate modules don't need to be reachable w.r.t. each other, since they can use PLT-style stubs.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, May 14, 2013 at 8:17 PM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi David,<br>
<br>
I believe that assertion indicates that something didn't get loaded into the lower 2GB of address space. That is, the memory manager isn't allocating memory in that range.<br>
<br>
I'm sure there must be a way to allocate memory in that range on FreeBSD. The system loader has to do it, right? I just don't know what makes it happen.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
-Andy<br>
<br>
-----Original Message-----<br>
From: Dr D. Chisnall [mailto:<a href="mailto:dc552@hermes.cam.ac.uk">dc552@hermes.cam.ac.uk</a>] On Behalf Of David Chisnall<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Sent: Friday, May 10, 2013 11:06 AM<br>
To: Kaylor, Andrew<br>
Cc: LLVM Developers Mailing List<br>
Subject: Re: TLS with MCJIT (an experimental patch)<br>
<br>
Without the MSP_32BIT part, I consistently hit this assertion:<br>
<br>
Assertion failed: ((Type == ELF::R_X86_64_32 && (Value <= UINT32_MAX)) || (Type == ELF::R_X86_64_32S && ((int64_t)Value <= INT32_MAX && (int64_t)Value >= INT32_MIN))), function resolveX86_64Relocation, file ../lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp,
line 222.<br>
<br>
David<br>
<br>
On 9 May 2013, at 13:58, "Kaylor, Andrew" <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<br>
<br>
> Can you try it without the MAP_32BIT part? It won't be as reliable, but if the memory addresses it is asking for are available it could work.<br>
><br>
> I agree that there are good reasons not to lock in on a single memory address, but I'm curious as to what other obstacles might be lurking behind the ones we know about. If the patch works when memory is loaded below 2GB then it would be possible to right
a sophisticated memory manager that surveys the available memory in that space and selects an appropriate block in some non-deterministic manner.<br>
><br>
> -Andy<br>
><br>
> -----Original Message-----<br>
> From: Dr D. Chisnall [mailto:<a href="mailto:dc552@hermes.cam.ac.uk">dc552@hermes.cam.ac.uk</a>] On Behalf Of David Chisnall<br>
> Sent: Wednesday, May 08, 2013 6:53 PM<br>
> To: Kaylor, Andrew<br>
> Cc: LLVM Developers Mailing List<br>
> Subject: Re: TLS with MCJIT (an experimental patch)<br>
><br>
> Hi,<br>
><br>
> Unfortunately, I can't compile this patch. MAP_32BIT is a Linuxism that doesn't work on FreeBSD (or OS X, or, as far as I can tell, anywhere except Linux). We can consider adding something similar to FreeBSD (although I'm hesitant to encourage anything
that increases the determinism of the memory layout of JITed code, for security reasons), but it doesn't seem ideal.<br>
><br>
> David<br>
><br>
> On 8 May 2013, at 16:54, "Kaylor, Andrew" <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<br>
><br>
>> Hi David,<br>
>><br>
>> Following up on the problems we discussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch.<br>
>><br>
>> This patch makes three changes:<br>
>><br>
>> 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default.<br>
>> 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary.<br>
>> 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols.<br>
>><br>
>> Of these changes, items 2 and 3 are probably reasonable things to commit into trunk, and depending on how this turns out I will do so. Item 1 is a bit heavy-handed as presented here, but it suggests the type of thing that subclasses of SectionMemoryManager
could do to make this work. If we had a way to communicate the code model to the memory manager from RuntimeDyld/MCJIT (and we obviously should!) then SectionMemoryManager could do something like this when small or medium memory models are selected on applicable
platforms.<br>
>><br>
>> When I tried this patch with the test case you provided yesterday it got through the compilation phase with lli using the small code model and the static relocation model, but it ultimately failed (but failed gracefully) because it couldn't resolve the '_ThreadRuneLocale'
symbol. Resolution of external symbols is meant to be handled by the memory manager, so I thought perhaps you could get something working with this patch.<br>
>><br>
>> Please give this a try and let me know how it works.<br>
>><br>
>> Thanks,<br>
>> Andy<br>
>> <tls-experimental.patch><br>
><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">
http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>