Javed Absar via llvm-dev
2017-Mar-14 09:25 UTC
[llvm-dev] [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>
Reid Kleckner via llvm-dev
2017-Mar-14 18:15 UTC
[llvm-dev] [cfe-dev] proposal - pragma section directive in clang
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>
James Molloy via llvm-dev
2017-Mar-14 20:02 UTC
[llvm-dev] [cfe-dev] proposal - pragma section directive in clang
Hi Reid, Unfortunately yes, it is.> If we do go with approach 3, I'd recommend adding a single metadataattachment 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>