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

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>> 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/4f802839/attachment.html>

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>

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