<div dir="ltr">Hi Reid,<div><br></div><div>Unfortunately yes, it is.</div><div><br></div><div>> <span style="color:rgb(33,33,33)">If we do go with approach 3, I'd recommend adding a single metadata attachment that controls all sections a global could possibly live in (text, data, rdata, bss).</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">I agree with this, although I think using metadata here wouldn't be right - don't we need to use attributes when dropping metadata would cause miscompiles?</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">I was considering adding an attributeset to global variables, so we'd have something like:</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">global i32* @g = i32 0, #0</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">#0 = attributes {bss_seg="...", text_seg="...", data_seg="..."}</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">Cheers,</span></div><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">James</span></div><div><span style="color:rgb(33,33,33)"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 14 Mar 2017 at 18:15 Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Is that actually an important use case? It sounded like it wasn't, and if we pursue option 3, we need to staple three pieces of data to every global: the default section to use if the global would live in .data, .rdata, or .bss.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">My main goal here is to eliminate complexity for what is for most users probably going to be a very niche feature, so if we can simply document that the pragma affects all globals in the TU and call it a day, I'd be happy with that.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If we do go with approach 3, I'd recommend adding a single metadata attachment that controls all sections a global could possibly live in (text, data, rdata, bss). This avoids having three attachments with three separate hashtable entries on every global variable we emit when the pragma is active.</div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Mar 14, 2017 at 2:25 AM, Javed Absar <span dir="ltr" class="gmail_msg"><<a href="mailto:Javed.Absar@arm.com" class="gmail_msg" target="_blank">Javed.Absar@arm.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div id="m_-7368308768773358365m_-7725832211118495635divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr" class="gmail_msg">
<p class="gmail_msg"></p>
<div class="gmail_msg">
<p class="gmail_msg">Thanks Reid/Jonathon for your replies.</p>
<p class="gmail_msg"><br class="gmail_msg">
</p>
<p class="gmail_msg">Reid, <br class="gmail_msg">
</p>
<p class="gmail_msg">An important case against module level flags is that it wont allow changing or resetting section names e.g.</p>
<p class="gmail_msg"><br class="gmail_msg">
</p>
<p class="gmail_msg">int a;</p>
<p class="gmail_msg">#pragma clang section bss = "xyz"</p>
<p class="gmail_msg">int b;</p>
<p class="gmail_msg"><br class="gmail_msg">
</p>
<p class="gmail_msg">In case above, users would like to see only 'b' placed in 'xyz' and not 'a' as well.<br class="gmail_msg">
</p>
<p class="gmail_msg">Link pointed to by Jonathon seems to require same behavior. <br class="gmail_msg">
</p>
<p class="gmail_msg"><br class="gmail_msg">
</p>
<p class="gmail_msg">Jonathon,</p>
<p class="gmail_msg">We are happy to revise the spelling to -<br class="gmail_msg">
</p>
<p class="gmail_msg">#pragma clang section bss = "xyz" <br class="gmail_msg">
</p>
<p class="gmail_msg">as you propose.</p>
Best Regards, Javed.</div>
<font style="font-size:11pt" face="Calibri, sans-serif" color="#000000" class="gmail_msg"><b class="gmail_msg"><br class="gmail_msg">
</b></font>
<p class="gmail_msg"></p>
<p class="gmail_msg"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000" class="gmail_msg"><b class="gmail_msg">From:</b> Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com" class="gmail_msg" target="_blank">jonathan@codesourcery.com</a>></font><br class="gmail_msg">
</p>
<div dir="ltr" class="gmail_msg">
<div id="m_-7368308768773358365m_-7725832211118495635x_divRplyFwdMsg" dir="ltr" class="gmail_msg"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000" class="gmail_msg"><b class="gmail_msg">Sent:</b> 13 March 2017 18:12:57<br class="gmail_msg">
<b class="gmail_msg">To:</b> James Molloy; Reid Kleckner; Javed Absar<br class="gmail_msg">
<b class="gmail_msg">Cc:</b> LLVM Dev; nd; <a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="gmail_msg">
<b class="gmail_msg">Subject:</b> Re: [llvm-dev] [cfe-dev] proposal - pragma section directive in clang</font>
<div class="gmail_msg"> </div>
</div>
</div><div class="gmail_msg"><div class="m_-7368308768773358365h5 gmail_msg">
<font size="2" class="gmail_msg"><span style="font-size:10pt" class="gmail_msg">
<div class="m_-7368308768773358365m_-7725832211118495635PlainText gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
On 3/10/17 2:47 AM, James Molloy via llvm-dev wrote:<br class="gmail_msg">
> +llvm-dev properly this time.<br class="gmail_msg">
><br class="gmail_msg">
> On Fri, 10 Mar 2017 at 09:42 James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="gmail_msg" target="_blank">james@jamesmolloy.co.uk</a><br class="gmail_msg">
> <<a href="mailto:james@jamesmolloy.co.uk" class="gmail_msg" target="_blank">mailto:james@jamesmolloy.co.uk</a>>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> The documentation is here:<br class="gmail_msg">
> <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html" class="gmail_msg" target="_blank">
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1359124985290.html</a><br class="gmail_msg">
><br class="gmail_msg">
> ** Proposed syntax and (vague) semantics **<br class="gmail_msg">
><br class="gmail_msg">
> As this is a new pragma for Clang and isn't ARM-specific, we've<br class="gmail_msg">
> invented a less ARM-specific syntax. Bikeshedding is expected and<br class="gmail_msg">
> welcome.<br class="gmail_msg">
><br class="gmail_msg">
> #pragma clang section bss(".mybss") rodata(".myrodata")<br class="gmail_msg">
> data(".mydata") text(".mytext")<br class="gmail_msg">
<br class="gmail_msg">
There's some prior art in the GreenHills compiler too, where the example <br class="gmail_msg">
above would be spelled:<br class="gmail_msg">
<br class="gmail_msg">
#pragma ghs section bss=".mybss", rodata=".myrodata", <br class="gmail_msg">
data=".mydata", text=".mytext"<br class="gmail_msg">
<br class="gmail_msg">
Maybe it's worth using that syntax, i.e:<br class="gmail_msg">
<br class="gmail_msg">
#pragma clang section bss=".mybss", rodata=".myrodata", <br class="gmail_msg">
data=".mydata", text=".mytext"<br class="gmail_msg">
<br class="gmail_msg">
Alternatively, supporting vendor-specific spellings might be useful, if <br class="gmail_msg">
there's a consistency argument to be made for clang doing it its own way.<br class="gmail_msg">
<br class="gmail_msg">
Docs are pages 108/109 here:<br class="gmail_msg">
<a href="http://www.ece.ualberta.ca/~cmpe490/documents/ghs/build_arm.pdf" class="gmail_msg" target="_blank">http://www.ece.ualberta.ca/~cmpe490/documents/ghs/build_arm.pdf</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Jon<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> The pragma applies to all global variable and function declarations<br class="gmail_msg">
> from the pragma to the end of the translation unit. The pragma<br class="gmail_msg">
> should ideally be pushable and poppable, but that is outside the<br class="gmail_msg">
> scope of this RFC. The pragma also applies to static local<br class="gmail_msg">
> declarations within functions.<br class="gmail_msg">
><br class="gmail_msg">
> All global variables and functions affected by this pragma have<br class="gmail_msg">
> their default ELF section destinations changed. Globals with<br class="gmail_msg">
> __attribute__((section())) are not affected (the attribute trumps<br class="gmail_msg">
> the pragma).<br class="gmail_msg">
><br class="gmail_msg">
> This pragma is only defined to work sensibly for ELF targets.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
-- <br class="gmail_msg">
Jon Roelofs<br class="gmail_msg">
<a href="mailto:jonathan@codesourcery.com" class="gmail_msg" target="_blank">jonathan@codesourcery.com</a><br class="gmail_msg">
CodeSourcery / Mentor Embedded<br class="gmail_msg">
</div>
</span></font></div></div></div>
</div>
</blockquote></div><br class="gmail_msg"></div>
</blockquote></div>