<div dir="ltr">Raphael,<div><br></div><div>Just wanted to follow up. Looks like with these two patches applied, I can get the elf size down but I have to add en extra ALIGN before specifying the first pointer address.</div><div><br></div><div>
<p class=""><span class="">. = ALIGN(</span><span class="">0x4</span><span class="">);</span></p>
<p class=""><span class="">. = </span><span class="">0x20000</span><span class="">;</span></p>
<p class=""><span class="">.text : {</span></p><p class=""><span class=""> ....</span></p><p class=""><span class="">}</span></p><p class="">Other than that this is looking good.<br></p><p class="">Thanks,<br></p><p class=""><span class="">Ed</span></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 6, 2015 at 9:18 AM, <a href="mailto:ed@modk.it">ed@modk.it</a> <span dir="ltr"><<a href="mailto:ed@modk.it" target="_blank">ed@modk.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Raphael,<div><br></div><div>I spoke too soon. While I can produce the correct binary after passing the lld built elf (using binutils objcopy), the elf itself is still way too large.</div><div><br></div><div>Your patch doesn't seem to work for my case for shrinking the elf. I have a hack that works for our specific case so I'll see if I can figure out what's missing in your general patch.</div><div><br></div><div>Thanks,</div><div>Ed</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 6, 2015 at 8:25 AM, <a href="mailto:ed@modk.it" target="_blank">ed@modk.it</a> <span dir="ltr"><<a href="mailto:ed@modk.it" target="_blank">ed@modk.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Raphael,<div><br></div><div>Thanks for the quick responses. I was able to get things working as is.</div><div><br></div><div>It turns out we don't actually want to put the .data segment way up there where it would be in actual memory, we just wanted a reference to where it would end up for our c startup routine to move the c initialization data (this is for baremetal ARM stuff) from it's actual location in flash to where it would be accessed in ram. But it looks like we can just leave it in flash. And since .bss takes no space (SHT_NOBITS) we can just set .bss to the beginning of ram.</div><div><br></div><div>So we end up with something like:</div><div><br></div><div><span><p style="font-size:12.8000001907349px">SECTIONS</p><p style="font-size:12.8000001907349px"> {</p><p style="font-size:12.8000001907349px"> . = 0x20000;</p><p style="font-size:12.8000001907349px"> .text :</p><p style="font-size:12.8000001907349px"> {</p><p style="font-size:12.8000001907349px"> ...</p><p style="font-size:12.8000001907349px"> }</p><p style="font-size:12.8000001907349px"> </p><p style="font-size:12.8000001907349px"> _etext = .;</p></span><p style="font-size:12.8000001907349px"> <span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">_data = .;</span></p><p style="font-size:12.8000001907349px"> .data :</p><p style="font-size:12.8000001907349px"> {</p><p style="font-size:12.8000001907349px"> ... </p><p style="font-size:12.8000001907349px"> }</p><p style="font-size:12.8000001907349px"> . = 0x20005000;</p><p style="font-size:12.8000001907349px"> .bss :</p><p style="font-size:12.8000001907349px"> {</p><p style="font-size:12.8000001907349px"> ... </p><p style="font-size:12.8000001907349px"> }</p><p style="font-size:12.8000001907349px"></p><p style="font-size:12.8000001907349px">}</p><p style="font-size:12.8000001907349px"><br></p><p style="font-size:12.8000001907349px">We're going to add support for some additional microcontrollers so I'll look into what it will take to add the MEMORY support. But it looks like we'll never actually have those large gaps after all. </p><p style="font-size:12.8000001907349px"><br></p><p style="font-size:12.8000001907349px">Thanks again,</p><p style="font-size:12.8000001907349px">Ed</p></div><div><br></div>
</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 6, 2015 at 1:50 AM, Rafael Auler <span dir="ltr"><<a href="mailto:rafaelauler@gmail.com" target="_blank">rafaelauler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ed,<div><br></div><div>I wrote <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10952&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-_Vb5O2etrrgPBMHSS3HBSolG6ree5dqEqmm_FCyAe0&s=E7AWM-vyrsazcH1RIkwTqsBYfYjQPgyDDbUUFlhAhdk&e=" target="_blank">http://reviews.llvm.org/D10952</a> to address your last problem. There is also the related <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10918&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-_Vb5O2etrrgPBMHSS3HBSolG6ree5dqEqmm_FCyAe0&s=ish0ynQCW_7GYzPiDGF4k7-UmYz-EFtpWzVMGYVAAsw&e=" target="_blank">http://reviews.llvm.org/D10918</a> by Denis to address how you can directly assign sections to segments in the script. Both are in code review.</div><div><br></div><div>Rafael auelr</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 12:29 AM, Rafael Auler <span dir="ltr"><<a href="mailto:rafaelauler@gmail.com" target="_blank">rafaelauler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ed,<div><br></div><div>It looks like lld is failing at mapping two sections far apart from each other into two different segments. Since it puts these two sections (.text and .data) in the same ELF segment, the segment is forced to be huge because the start addresses of these sections are far apart from each other. I would begin by investigating how TargetLayout<ELFT>::assignSectionsToSegments() works and go from there. This function lives at lld/lib/ReaderWriter/ELF/TargetLayout.cpp. I don't believe you can try any other flags to try to get this done without fixing this logic.</div><div><br></div><div>Rafael Auler</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jul 1, 2015 at 12:00 PM, <a href="mailto:ed@modk.it" target="_blank">ed@modk.it</a> <span dir="ltr"><<a href="mailto:ed@modk.it" target="_blank">ed@modk.it</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi All,<div><br></div><div>Congratulations on the major progress on the llvm linker lld over the past year including the new linker script support. This really makes it possible to ditch binutils altogether. It looks like lld's MEMORY sections are currently parsed but not evaluated, but so far that hasn't been a problem.</div><div><br></div><div>The only snag is I can't figure out how to define the start of the .data section in a sane way. Let's say we want our flash (.text) section to start at address 0x20000 with a max size of 0x8000 bytes and a data section start at 0x20005000 with a max length of 0x3000 bytes. We'd usually accomplish this with a combination of MEMORY and SECTION entries in the linker script tied together by region aliases, the "AT" directive and the ">" operator:</div><div><br></div><div>
<p><span>MEMORY</span></p>
<p><span>{</span></p>
<p><span> flash (rx) : ORIGIN = </span><span>0x20000</span><span>, LENGTH = </span><span>0x8000</span></p>
<p><span> ram (rwx) : ORIGIN = </span><span>0x20005000</span><span>, LENGTH = </span><span>0x00003000</span></p>
<p><span>}</span></p>
<p><span><br>
</span></p>
<p><span>REGION_ALIAS(</span><span>"REGION_TEXT"</span><span>, flash);</span></p>
<p><span>REGION_ALIAS(</span><span>"REGION_RAM"</span><span>, ram);</span></p>
<p><span><br>
</span></p>
<p><span>SECTIONS</span></p>
<p><span>{</span></p>
<p><span> .text :</span></p>
<p><span> {</span></p>
<p><span> ...</span></p>
<p><span> } > REGION_TEXT</span></p>
<p><span> </span></p>
<p><span> _etext = .;</span></p>
<p><span> .data :</span></p>
<p><span> {</span></p>
<p><span> ...</span></p>
<p><span> } > REGION_RAM AT > REGION_TEXT</span></p>
<p><span></span><br></p>
<p><span>}</span></p>
<p><br></p><p>But the MEMORY entries don't seem to be evaluated and ">", "AT", and "REGION_ALIAS" don't seem to be hooked up either. Command line options like "<span style="font-family:arial,helvetica,sans-serif">-Tdata=org=0x20005000" or "--section-start=.data=</span><span style="font-family:arial,helvetica,sans-serif"> 0x20005000" are also not working. </span></p><p><span style="font-family:arial,helvetica,sans-serif"><br></span></p><p><span style="font-family:arial,helvetica,sans-serif">However, t</span><span style="font-family:arial,helvetica,sans-serif">he following linker script gets us close:</span></p><p><span style="font-family:arial,helvetica,sans-serif"><br></span></p><p><span>SECTIONS</span></p><p><span> {</span></p><p><span> . = </span>0x20000;</p><p><span> .text :</span></p><p><span> {</span></p><p><span> ...</span></p><p><span> }</span></p><p><span> </span> </p><p><span> _etext = .;</span></p><p><span> </span><span>. = 0x20005000;</span></p><p><span> _data = .;</span></p><p><span> .data :</span></p><p><span> {</span></p><p><span> ...</span> </p><p><span> }</span></p><p>
</p><p><span>}</span></p><p><span><br></span></p><p><span style="font-family:arial,helvetica,sans-serif">The only problem is the resulting elf and binary files are HUGE (e.g. elf is 500mb vs 50k) as the linker seems to be filling the space between the end of text and the beginning of data. A "</span>llvm-readobj -s" on the resulting elf is nearly identical to one created with binutils except binults-ld puts .data at Address: 0x20005000 Offset: 0xD000 and llvm-lld has data at Address: 0x20005000 Offset: 0x1FFED000 (based on start address of 0x18000.)</p>
<p><span style="font-family:arial,helvetica,sans-serif">Any thoughts on a supported linker flag or linker script option that can help here? Or a source file to dive into to get something working? I'd be willing to take a pass at completing the MEMORY section implementation if that's the most sane way to move forward but would love a pointer in the right direction.</span></p><p><span style="font-family:arial,helvetica,sans-serif"><br></span></p><p><span style="font-family:arial,helvetica,sans-serif">Thanks,</span></p><p><span style="font-family:arial,helvetica,sans-serif">Ed</span></p></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><br></div></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>