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

[James Molloy via cfe-dev]

Hi Reid,

Unfortunately yes, it is.

> 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).

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?

I was considering adding an attributeset to global variables, so we'd have
something like:

global i32* @g = i32 0, #0

#0 = attributes {bss_seg="...", text_seg="...", data_seg="..."}

Cheers,

James


On Tue, 14 Mar 2017 at 18:15 Reid Kleckner <rnk at google.com> wrote:

> 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/cfe-dev/attachments/20170314/6fcc87e7/attachment.html>