<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi All,<br>
<br>
We supply both clang and gcc builds in our Crossworks for ARM
product that have command line options to name the default section
names used by the compiler for example<br>
<br>
-mtext=.text.libdebugio -mdata=.data.libdebugio
-mbss=.bss.libdebugio -mrodata=.rodata.libdebugio<br>
<br>
Without this placing code/data into sections (in the presence of
-ffunction-sections -fdata-sections) is pretty much impossible
with binutils objcopy/ld.<br>
<br>
Is it worth considering this as an alternative/addition to
#pragmas? Patch files are available here<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.rowley.co.uk/crossworks/gpl_sources.htm">http://www.rowley.co.uk/crossworks/gpl_sources.htm</a><br>
<br>
if anyone is interested.<br>
<br>
Regards<br>
Michael<br>
<br>
</div>
<blockquote
cite="mid:CALCTSA3Uyv1ROvfaasGNKQkjHn1H09_4pZUi_KCuKNi2Xt37jA@mail.gmail.com"
type="cite">
<div dir="ltr">+llvm-dev properly this time.<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, 10 Mar 2017 at 09:42 James Molloy <<a
moz-do-not-send="true"
href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</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">
<div class="gmail_msg">Hi Reid, all,</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">+llvm-dev as this RFC involves
changes in Clang and LLVM.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This RFC has stagnated and I think
that's partially because the proposal isn't particularly
elegant and is light on details. We've been having a
rethink and have a slightly different implementation to
propose that we (I) hope will be nicer.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">** Rationale (for llvm-dev) **</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The goal of this proposed feature
is to provide a migration path toward Clang for
developers in the automotive domain. As Javed has
mentioned, AUTOSAR, an automotive standard, mandates the
use of a #pragma in header files to determine in which
sections initialized and uninitialized data get put.</div>
</div>
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This feature is implemented in our
legacy ARM Compiler 5 toolchain and we're also aware of
GCC forks used across the automotive space that have
this feature implemented compatible with the ARM
Compiler 5 implementation.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The documentation is here: <a
moz-do-not-send="true"
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></div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
</div>
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">** Proposed syntax and (vague)
semantics **</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">As this is a new pragma for Clang
and isn't ARM-specific, we've invented a less
ARM-specific syntax. Bikeshedding is expected and
welcome.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg"> #pragma clang section
bss(".mybss") rodata(".myrodata") data(".mydata")
text(".mytext")</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The pragma applies to all global
variable and function declarations from the pragma to
the end of the translation unit. The pragma should
ideally be pushable and poppable, but that is outside
the scope of this RFC. The pragma also applies to static
local declarations within functions.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">All global variables and functions
affected by this pragma have their default ELF section
destinations changed. Globals with
__attribute__((section())) are not affected (the
attribute trumps the pragma).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This pragma is only defined to work
sensibly for ELF targets.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">** Proposed implementation **</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">There are, I believe, three
possible implementation stategies:</div>
<div class="gmail_msg"> 1) Clang internally sets the
"section" on all globals it creates. No changes in LLVM.</div>
<div class="gmail_msg"> 2) Clang sets some module-level
attribute describing the default section names. The LLVM
backend takes this into account when deciding the
section name for a global when it emits it (AsmPrinter).</div>
<div class="gmail_msg"> 3) Clang sets the default section
names as attributes on all globals. The LLVM backend
takes this into account when deciding the section name
for a global when it emits it (AsmPrinter).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">(1) and (3) work with LTO. (2)
interacts badly with LTO so is discounted.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">(1) requires Clang to perform the
decision into exactly what section a global will go,
which is the wrong place for several previously
mentioned reasons (midend optimizations could promote
.data -> .bss, clang currently doesn't have the
mechanics to test if an initializer is zero or not, LLVM
does).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">(2) and (3) have the advantage that
the section type does not need to be inferred by LLVM
from its name. This means we don't need the horrible
string matching (m/^.bss./ -> BSS, m/^.data./ ->
Data, etc) in the AsmPrinter - users can specify
whatever names they like for bss sections without
confusing the compiler.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Our previous proposal was (1). We
are now proposing (3).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">For (3), I think there are three
distinct steps, none of which are *particularly*
invasive:</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg"> a) Allow arbitrary attributes on
GlobalVariables. Currently these are restricted to
Functions only; I believe mainly because noone had a
usecase for attributes on variables.</div>
<div class="gmail_msg"> b) Teach the clang frontend about
the new pragma and CodeGen to add the attributes to
globals</div>
<div class="gmail_msg"> c) Teach AsmPrinter to inspect
these attributes if they exist and take them into
account when choosing sections.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">All comments more than welcome,</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">James</div>
</div>
<br class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Fri, 3 Mar 2017 at
09:09 James Molloy <<a moz-do-not-send="true"
href="mailto:james@jamesmolloy.co.uk"
class="gmail_msg" target="_blank">james@jamesmolloy.co.uk</a>>
wrote:<br class="gmail_msg">
</div>
<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 class="gmail_msg">Hi Reid,</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Thanks for your comments. In
truth, we don't have a particular requirement for
behaviour under LTO or pushability/poppability, so
we can define this in terms of what's best for
Clang.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">As context is always useful,
the goal of this proposed feature is to provide a
migration path toward Clang for developers in the
automotive domain. As Javed has mentioned, AUTOSAR
which is an automotive standard, mandates the use of
a #pragma in header files to determine in which
sections initialized and uninitialized data get put.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This feature is implemented in
our legacy ARM Compiler 5 toolchain and we're also
aware of GCC forks used across the automotive space
that have this feature implemented compatible with
the ARM Compiler 5 implementation.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">The documentation is here: <a
moz-do-not-send="true"
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></div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">We do not aim for or anticipate
syntax-level compatibility; merely the ability to do
something similar in Clang. In particular Clang
can't support the "section_type" specifier without
significant rewrite, as LLVM decides the section
type (NOBITS/PROGBITS) by textual matching on the
section name (gross, but the fix is well beyond our
scope).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Given that documentation, you
can also see why the Microsoft compatibility option
*almost* met our requirements - all except the
behaviour in this case:</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">#pragma bss_seg('.bss.mybss')</div>
<div class="gmail_msg">int i; // Microsoft extension
will put i in .bss.mybss</div>
<div class="gmail_msg">int j = 0; // Microsoft
extension will put j in .data, whereas we really
need it in .bss.mybss</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">So to specifically answer your
questions:</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">In ARM Compiler 5, all pragmas
are pushable and poppable. Clang doesn't have this
feature generally yet, but when/if it does, I don't
see why this pragma shouldn't be affected. So yes,
we should consider it pushable and poppable.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">I think the only reasonable
behaviour under LTO must be that the two TUs (may)
have different bss and data sections. Anything else
would be very strange behaviour from the user's
perspective.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Your example of a static global
migrating from .data into .bss after optimization is
interesting. With our proposal to explicitly name
sections in IR, this optimization would be
inhibited. I personally think that's fine :)</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Cheers,</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">James</div>
</div>
<br class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div dir="ltr" class="gmail_msg">On Thu, 2 Mar 2017 at
21:42 Reid Kleckner via cfe-dev <<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:<br class="gmail_msg">
</div>
<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">Would these pragmas
be translation-unit global or could they be pushed
and popped like the MSVC pragmas?
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">If two TUs are combined
through LTO, can the two TUs have different bss
and data sections?</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">If the answer to both is
"no", then I think we should use a module flag
instead of manually setting the section from the
frontend.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Here is a C++ example
where, after optimization, a global may end up
in .bss instead of .data:</div>
<div class="gmail_msg">// c++</div>
<div class="gmail_msg">
<div class="gmail_msg">static int f() { return
0; }</div>
<div class="gmail_msg">static int x = f();</div>
<div class="gmail_msg">int *g() { return &x;
}</div>
</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">After global opt we get
this:</div>
<div class="gmail_msg">
<div class="gmail_msg">@_ZL1x = internal global
i32 0, align 4</div>
</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Normally LLVM will put this
in .bss or use .lcomm for it. Your proposal will
put it in the user's data section instead of
their bss section. If that's important, we
should use a module flag for this.</div>
</div>
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
<div class="gmail_quote gmail_msg">On Thu, Mar 2,
2017 at 11:35 AM, Javed Absar via cfe-dev <span
dir="ltr" class="gmail_msg"><<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</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 link="#0563C1" vlink="#954F72"
class="gmail_msg" lang="EN-GB">
<div
class="m_-1134757355221584237m_415161867628613655m_3187848934551112840m_3527854597707582817WordSection1
gmail_msg">
<p class="MsoNormal gmail_msg"><span
style="color:black" class="gmail_msg">Hi
all:</span></p>
<p class="MsoNormal gmail_msg"><span
style="color:black" class="gmail_msg"> </span></p>
<p class="MsoNormal gmail_msg"><span
style="color:black" class="gmail_msg">We
would like to propose a clang pragma
directive to allow specialized section
names.<br class="gmail_msg">
The semantics of it could be as
follows. The pragma section name is
declared in global<br
class="gmail_msg">
scope. All global variables and
functions get assigned to the
corresponding specialized<br
class="gmail_msg">
section name if one is present. With
this feature, the following code:<br
class="gmail_msg">
<br class="gmail_msg">
// foo.c<br class="gmail_msg">
#pragma bss_section(".bss.alpha")<br
class="gmail_msg">
#pragma data_section(".data.beta")<br
class="gmail_msg">
#pragma code_section(".code.gamma")<br
class="gmail_msg">
#pragma const_section(".const.delta")<br
class="gmail_msg">
int a;<br class="gmail_msg">
int b=2;<br class="gmail_msg">
const int d = 5;<br class="gmail_msg">
int c(){<br class="gmail_msg">
return d;<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
..will emit llvm-ir as:<br
class="gmail_msg">
<br class="gmail_msg">
target triple = "armv7-arm-none-eabi"<br
class="gmail_msg">
@a = global i32 0, section
".bss.alpha", align 4<br
class="gmail_msg">
@b = global i32 2, section
".data.beta", align 4<br
class="gmail_msg">
@d = constant i32 5, section
".const.delta", align 4<br
class="gmail_msg">
<br class="gmail_msg">
; Function Attrs: noinline nounwind<br
class="gmail_msg">
define i32 @c() #0 section
".code.gamma" {<br class="gmail_msg">
entry:<br class="gmail_msg">
ret i32 5<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
This pragma will be very useful for
embedded code which<br
class="gmail_msg">
need to control where the different
sections are placed in memory.<br
class="gmail_msg">
<br class="gmail_msg">
Microsoft -fms-extension provides
similar feature, but our proposal is
for a <br class="gmail_msg">
general use. Attributes are an
alternative that is also currently
available,<br class="gmail_msg">
but attributes are applicable only to
specific declarations and not entire<br
class="gmail_msg">
file. Many real embedded users prefer
the pragma option.<br
class="gmail_msg">
This will be a welcome enabler for
them. Also, </span>AUTOSAR, which is
an</p>
<p class="MsoNormal gmail_msg">automotive
standard mandates use of a #pragma
solution over an attribute one<span
style="color:black" class="gmail_msg"><br
class="gmail_msg">
<br class="gmail_msg">
Looking forward to comments and
suggestions.<br class="gmail_msg">
</span>Best Regards<span
class="m_-1134757355221584237m_415161867628613655m_3187848934551112840HOEnZb
gmail_msg"></span></p>
<span
class="m_-1134757355221584237m_415161867628613655m_3187848934551112840HOEnZb
gmail_msg"><font class="gmail_msg"
color="#888888">
<p class="MsoNormal gmail_msg">Javed</p>
</font></span></div>
</div>
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
cfe-dev mailing list<br class="gmail_msg">
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br
class="gmail_msg">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" class="gmail_msg"
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br
class="gmail_msg">
<br class="gmail_msg">
</blockquote>
</div>
<br class="gmail_msg">
</div>
_______________________________________________<br
class="gmail_msg">
cfe-dev mailing list<br class="gmail_msg">
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br
class="gmail_msg">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br
class="gmail_msg">
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>