[llvm-dev] [cfe-dev] proposal - pragma section directive in clang

[Reid Kleckner via llvm-dev]

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.

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.

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.

On Tue, Mar 14, 2017 at 2:25 AM, Javed Absar <Javed.Absar at arm.com> wrote:

> Thanks Reid/Jonathon for your replies.
>
>
> Reid,
>
> An important case against module level flags is that it wont allow
> changing or  resetting section names e.g.
>
>
> int a;
>
> #pragma clang section bss = "xyz"
>
> int b;
>
>
> In case above, users would like to see only 'b' placed in 'xyz' and
> not 'a' as well.
>
> Link pointed to by Jonathon seems to require same behavior.
>
>
> Jonathon,
>
> We are happy to revise the spelling to -
>
> #pragma clang section bss = "xyz"
>
> as you propose.
> Best Regards, Javed.
>
> *From:* Jonathan Roelofs <jonathan at codesourcery.com>
> *Sent:* 13 March 2017 18:12:57
> *To:* James Molloy; Reid Kleckner; Javed Absar
> *Cc:* LLVM Dev; nd; cfe-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [cfe-dev] proposal - pragma section directive
> in clang
>
>
>
> On 3/10/17 2:47 AM, James Molloy via llvm-dev wrote:
> > +llvm-dev properly this time.
> >
> > On Fri, 10 Mar 2017 at 09:42 James Molloy <james at jamesmolloy.co.uk
> > <mailto:james at jamesmolloy.co.uk <james at jamesmolloy.co.uk>>> wrote:
> >
>
> >
> >     The documentation is here:
> >     http://infocenter.arm.com/help/index.jsp?topic=/com.arm.
> doc.dui0472m/chr1359124985290.html
> >
> >     ** Proposed syntax and (vague) semantics **
> >
> >     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.
> >
> >       #pragma clang section bss(".mybss") rodata(".myrodata")
> >     data(".mydata") text(".mytext")
>
> There's some prior art in the GreenHills compiler too, where the example
> above would be spelled:
>
>      #pragma ghs section bss=".mybss", rodata=".myrodata",
> data=".mydata", text=".mytext"
>
> Maybe it's worth using that syntax, i.e:
>
>      #pragma clang section bss=".mybss", rodata=".myrodata",
> data=".mydata", text=".mytext"
>
> Alternatively, supporting vendor-specific spellings might be useful, if
> there's a consistency argument to be made for clang doing it its own way.
>
> Docs are pages 108/109 here:
> http://www.ece.ualberta.ca/~cmpe490/documents/ghs/build_arm.pdf
>
>
> Jon
>
> >
> >     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.
> >
> >     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).
> >
> >     This pragma is only defined to work sensibly for ELF targets.
> >
>
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/c78e4ac3/attachment.html>