Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-26 Thread Luis R. Rodriguez 
On Fri, Aug 26, 2016 at 05:33:38PM +1000, Nicholas Piggin wrote:
> On Thu, 25 Aug 2016 23:38:44 -0700
> "Luis R. Rodriguez"  wrote:
> > > > > > Ah, thing is we use this for both linktables and section ranges.
> > > > > > Or do we want macros for both that do the same thing ?  
> > > > >
> > > > > I think it would make the code using it more readable.  
> > > >
> > > > Alrighty... so:
> > > >
> > > > LINKTABLE_START()
> > > > LINKTABLE_END()
> > > >
> > > > SECTION_RANGE_START()
> > > > SECTION_RANGE_END()
> > > >
> > > > And these macros do the exact same thing. Ie, nothing shared. Right?  
> > >
> > > Yeah I think so. Internally they would probably be aliased to the
> > > same common definition (unless you had some type check or something),
> > > but user would know about such details.  
> > 
> > What name should we use for such common macro definition ?
> 
> 
> Ah, not really sure. I guess the "link table" is some kind of
> section range? I haven't actually looked closely at both of them
> in the subsequent patches. It matters less if it's not expected
> to be used as an API though.
> 

OK well, going with LINUX_SECTION_START() so we'll have:

#define LINKTABLE_START LINUX_SECTION_START
#define LINKTABLE_END   LINUX_SECTION_END

#define SECTION_RANGE_START LINUX_SECTION_START
#define SECTION_RANGE_END   LINUX_SECTION_END

Is that OK?

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-26 Thread Nicholas Piggin 
On Fri, 26 Aug 2016 15:22:19 +0200
"Luis R. Rodriguez"  wrote:

> On Fri, Aug 26, 2016 at 05:33:38PM +1000, Nicholas Piggin wrote:
> > On Thu, 25 Aug 2016 23:38:44 -0700
> > "Luis R. Rodriguez"  wrote:  
> > > > > > > Ah, thing is we use this for both linktables and section ranges.
> > > > > > > Or do we want macros for both that do the same thing ?
> > > > > >
> > > > > > I think it would make the code using it more readable.
> > > > >
> > > > > Alrighty... so:
> > > > >
> > > > > LINKTABLE_START()
> > > > > LINKTABLE_END()
> > > > >
> > > > > SECTION_RANGE_START()
> > > > > SECTION_RANGE_END()
> > > > >
> > > > > And these macros do the exact same thing. Ie, nothing shared. Right?  
> > > > >   
> > > >
> > > > Yeah I think so. Internally they would probably be aliased to the
> > > > same common definition (unless you had some type check or something),
> > > > but user would know about such details.
> > > 
> > > What name should we use for such common macro definition ?  
> > 
> > 
> > Ah, not really sure. I guess the "link table" is some kind of
> > section range? I haven't actually looked closely at both of them
> > in the subsequent patches. It matters less if it's not expected
> > to be used as an API though.
> >   
> 
> OK well, going with LINUX_SECTION_START() so we'll have:
> 
> #define LINKTABLE_START   LINUX_SECTION_START
> #define LINKTABLE_END LINUX_SECTION_END
> 
> #define SECTION_RANGE_START   LINUX_SECTION_START
> #define SECTION_RANGE_END LINUX_SECTION_END
> 
> Is that OK?

I guess so, without having seen the updated, although I don't see why
you'd not just

#define LINKTABLE_START SECTION_RANGE_START

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-26 Thread Nicholas Piggin 
On Thu, 25 Aug 2016 23:38:44 -0700
"Luis R. Rodriguez"  wrote:

> On Aug 25, 2016 8:00 PM, "Nicholas Piggin"  wrote:
> >
> > On Thu, 25 Aug 2016 19:52:39 +0200
> > "Luis R. Rodriguez"  wrote:
> >  
> > > On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:  
> > > > On Thu, 25 Aug 2016 08:05:40 +0200
> > > > "Luis R. Rodriguez"  wrote:  
> > > > > > Oh, that makes more sense. The SECTION stuff and custom sections  
> was
> > > > > > confusing me. I would prefer just to drop all the LINUX_SECTION  
> naming
> > > > > > and make it match the functionality you're using. For example:
> > > > > >
> > > > > > +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> > > > > > +
> > > > > >  /* mutex to protect coming/going of the the jump_label table */
> > > > > >  static DEFINE_MUTEX(jump_label_mutex);
> > > > > >
> > > > > > @@ -274,8 +277,6 @@ static void __jump_label_update(struct  
> static_key *key,
> > > > > >
> > > > > >  void __init jump_label_init(void)
> > > > > >  {
> > > > > > -   struct jump_entry *iter_start = __start___jump_table;
> > > > > > -   struct jump_entry *iter_stop = __stop___jump_table;
> > > > > > struct static_key *key = NULL;
> > > > > > struct jump_entry *iter;
> > > > > >
> > > > > > @@ -292,9 +293,10 @@ void __init jump_label_init(void)
> > > > > > return;
> > > > > >
> > > > > > jump_label_lock();
> > > > > > -   jump_label_sort_entries(iter_start, iter_stop);
> > > > > > +   jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> > > > > > +   LINUX_SECTION_END(__jump_table));
> > > > > >
> > > > > > Now I think this is a fine abstraction to have.  
> > > > >
> > > > > OK will keep this one.
> > > > >  
> > > > > > I think it would look
> > > > > > even cleaner if you had:
> > > > > >
> > > > > > LINKTABLE_START(__jump_table)
> > > > > > LINKTABLE_END(__jump_table)
> > > > > >
> > > > > > Then do we need to even have the LINUX_SECTION middle man at all?  
> > > > >
> > > > > Ah, thing is we use this for both linktables and section ranges.
> > > > > Or do we want macros for both that do the same thing ?  
> > > >
> > > > I think it would make the code using it more readable.  
> > >
> > > Alrighty... so:
> > >
> > > LINKTABLE_START()
> > > LINKTABLE_END()
> > >
> > > SECTION_RANGE_START()
> > > SECTION_RANGE_END()
> > >
> > > And these macros do the exact same thing. Ie, nothing shared. Right?  
> >
> > Yeah I think so. Internally they would probably be aliased to the
> > same common definition (unless you had some type check or something),
> > but user would know about such details.  
> 
> What name should we use for such common macro definition ?


Ah, not really sure. I guess the "link table" is some kind of
section range? I haven't actually looked closely at both of them
in the subsequent patches. It matters less if it's not expected
to be used as an API though.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-26 Thread Luis R. Rodriguez 
On Aug 25, 2016 8:00 PM, "Nicholas Piggin"  wrote:
>
> On Thu, 25 Aug 2016 19:52:39 +0200
> "Luis R. Rodriguez"  wrote:
>
> > On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> > > On Thu, 25 Aug 2016 08:05:40 +0200
> > > "Luis R. Rodriguez"  wrote:
> > > > > Oh, that makes more sense. The SECTION stuff and custom sections
was
> > > > > confusing me. I would prefer just to drop all the LINUX_SECTION
naming
> > > > > and make it match the functionality you're using. For example:
> > > > >
> > > > > +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> > > > > +
> > > > >  /* mutex to protect coming/going of the the jump_label table */
> > > > >  static DEFINE_MUTEX(jump_label_mutex);
> > > > >
> > > > > @@ -274,8 +277,6 @@ static void __jump_label_update(struct
static_key *key,
> > > > >
> > > > >  void __init jump_label_init(void)
> > > > >  {
> > > > > -   struct jump_entry *iter_start = __start___jump_table;
> > > > > -   struct jump_entry *iter_stop = __stop___jump_table;
> > > > > struct static_key *key = NULL;
> > > > > struct jump_entry *iter;
> > > > >
> > > > > @@ -292,9 +293,10 @@ void __init jump_label_init(void)
> > > > > return;
> > > > >
> > > > > jump_label_lock();
> > > > > -   jump_label_sort_entries(iter_start, iter_stop);
> > > > > +   jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> > > > > +   LINUX_SECTION_END(__jump_table));
> > > > >
> > > > > Now I think this is a fine abstraction to have.
> > > >
> > > > OK will keep this one.
> > > >
> > > > > I think it would look
> > > > > even cleaner if you had:
> > > > >
> > > > > LINKTABLE_START(__jump_table)
> > > > > LINKTABLE_END(__jump_table)
> > > > >
> > > > > Then do we need to even have the LINUX_SECTION middle man at all?
> > > >
> > > > Ah, thing is we use this for both linktables and section ranges.
> > > > Or do we want macros for both that do the same thing ?
> > >
> > > I think it would make the code using it more readable.
> >
> > Alrighty... so:
> >
> > LINKTABLE_START()
> > LINKTABLE_END()
> >
> > SECTION_RANGE_START()
> > SECTION_RANGE_END()
> >
> > And these macros do the exact same thing. Ie, nothing shared. Right?
>
> Yeah I think so. Internally they would probably be aliased to the
> same common definition (unless you had some type check or something),
> but user would know about such details.

What name should we use for such common macro definition ?

  Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-25 Thread Nicholas Piggin 
On Thu, 25 Aug 2016 19:52:39 +0200
"Luis R. Rodriguez"  wrote:

> On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> > On Thu, 25 Aug 2016 08:05:40 +0200
> > "Luis R. Rodriguez"  wrote:  
> > > > Oh, that makes more sense. The SECTION stuff and custom sections was
> > > > confusing me. I would prefer just to drop all the LINUX_SECTION naming
> > > > and make it match the functionality you're using. For example:
> > > > 
> > > > +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> > > > +
> > > >  /* mutex to protect coming/going of the the jump_label table */
> > > >  static DEFINE_MUTEX(jump_label_mutex);
> > > >  
> > > > @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key 
> > > > *key,
> > > >  
> > > >  void __init jump_label_init(void)
> > > >  {
> > > > -   struct jump_entry *iter_start = __start___jump_table;
> > > > -   struct jump_entry *iter_stop = __stop___jump_table;
> > > > struct static_key *key = NULL;
> > > > struct jump_entry *iter;
> > > >  
> > > > @@ -292,9 +293,10 @@ void __init jump_label_init(void)
> > > > return;
> > > >  
> > > > jump_label_lock();
> > > > -   jump_label_sort_entries(iter_start, iter_stop);
> > > > +   jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> > > > +   LINUX_SECTION_END(__jump_table));
> > > > 
> > > > Now I think this is a fine abstraction to have.
> > > 
> > > OK will keep this one.
> > >   
> > > > I think it would look
> > > > even cleaner if you had:
> > > > 
> > > > LINKTABLE_START(__jump_table)
> > > > LINKTABLE_END(__jump_table)
> > > >
> > > > Then do we need to even have the LINUX_SECTION middle man at all?
> > > 
> > > Ah, thing is we use this for both linktables and section ranges.
> > > Or do we want macros for both that do the same thing ?  
> > 
> > I think it would make the code using it more readable.  
> 
> Alrighty... so:
> 
> LINKTABLE_START()
> LINKTABLE_END()
> 
> SECTION_RANGE_START()
> SECTION_RANGE_END()
> 
> And these macros do the exact same thing. Ie, nothing shared. Right?

Yeah I think so. Internally they would probably be aliased to the
same common definition (unless you had some type check or something),
but user would know about such details.

Thanks,
Nick

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-25 Thread Luis R. Rodriguez 
On Thu, Aug 25, 2016 at 04:51:21PM +1000, Nicholas Piggin wrote:
> On Thu, 25 Aug 2016 08:05:40 +0200
> "Luis R. Rodriguez"  wrote:
> > > Oh, that makes more sense. The SECTION stuff and custom sections was
> > > confusing me. I would prefer just to drop all the LINUX_SECTION naming
> > > and make it match the functionality you're using. For example:
> > > 
> > > +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> > > +
> > >  /* mutex to protect coming/going of the the jump_label table */
> > >  static DEFINE_MUTEX(jump_label_mutex);
> > >  
> > > @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key 
> > > *key,
> > >  
> > >  void __init jump_label_init(void)
> > >  {
> > > - struct jump_entry *iter_start = __start___jump_table;
> > > - struct jump_entry *iter_stop = __stop___jump_table;
> > >   struct static_key *key = NULL;
> > >   struct jump_entry *iter;
> > >  
> > > @@ -292,9 +293,10 @@ void __init jump_label_init(void)
> > >   return;
> > >  
> > >   jump_label_lock();
> > > - jump_label_sort_entries(iter_start, iter_stop);
> > > + jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> > > + LINUX_SECTION_END(__jump_table));
> > > 
> > > Now I think this is a fine abstraction to have.  
> > 
> > OK will keep this one.
> > 
> > > I think it would look
> > > even cleaner if you had:
> > > 
> > > LINKTABLE_START(__jump_table)
> > > LINKTABLE_END(__jump_table)
> > >
> > > Then do we need to even have the LINUX_SECTION middle man at all?  
> > 
> > Ah, thing is we use this for both linktables and section ranges.
> > Or do we want macros for both that do the same thing ?
> 
> I think it would make the code using it more readable.

Alrighty... so:

LINKTABLE_START()
LINKTABLE_END()

SECTION_RANGE_START()
SECTION_RANGE_END()

And these macros do the exact same thing. Ie, nothing shared. Right?

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-25 Thread Nicholas Piggin 
On Thu, 25 Aug 2016 08:05:40 +0200
"Luis R. Rodriguez"  wrote:

> On Thu, Aug 25, 2016 at 12:06:33PM +1000, Nicholas Piggin wrote:
> > On Wed, 24 Aug 2016 22:12:53 +0200
> > "Luis R. Rodriguez"  wrote:  
> > > But:
> > > 
> > > git grep SECTION_TEXT works as expected immediately.
> > > 
> > > I guess its a matter of perspective.
> > >   
> > > > They are also
> > > > the names you'll be grepping for when you look at disassembly.
> > > 
> > > Sure but if you're grepping asm, you very likely know what to look for.  
> > 
> > After you have gone through the extra layer of naming indirection
> > to work out what it is. I'm still not sold on the name indirection
> > and hiding wildcards. Not just for asm grepping, but I don't think
> > it's a negative thing for devs working on the linker to know what
> > actual section names and commands are being used, as much as possible.  
> 
> OK lets see what it looks like after dropping them. Will try that.
> 
> > > The idea was to add helpers to do the globbing more easily.
> > > 
> > > The glob for sections now documented   is SECTION_ALL()
> > > The glob that is range specificis SECTION_RNG_ALL()
> > > The glob that is linker table specific is SECTION_TBL_ALL()  
> > 
> > I still don't see this is better than
> > 
> > .text*
> > .text.*
> > .text.range.*
> > .text.table.*
> > etc.  
> 
> OK will drop it.

Thank you for considering it, I appreciate that.


> > > How about:
> > > 
> > > At the top just use "Linux sections helpers"
> > > 
> > > Then:
> > > 
> > > /**
> > >  * DOC: Introduction
> > >  *
> > >  * We document below a dedicated set of helpers used in Linux to make 
> > > sections
> > >  * defined in the Linux linker script accessible in C code in a generic 
> > > form and 
> > >  * and provide certain attributes about them.
> > >  */
> > >   
> > > > I just can't work out what exactly is a
> > > > "custom Linux section", and what DECLARE_LINUX_SECTION(), for example, 
> > > > actaully
> > > > gives you.
> > > 
> > > Its a way to replace the:
> > > 
> > > extern char foo[], foo__end[];
> > > 
> > > So this provides a generalized form to use declarations used in C code to 
> > > make
> > > the linker script start and end symbols from esctions accessible in C 
> > > code. Since
> > > DEFINE_SECTION_RANGE() and DEFINE_LINKTABLE() macros use this, then the
> > > DECLARE_LINUX_SECTION() is only needed if you need access to these 
> > > symbols in C
> > > code outside of the one that is defining and mainly in charge of managing 
> > > the
> > > section. We provide DECLARE_*() helpers for section ranges and linker 
> > > tables
> > > though so those can be used instead to help annotate the type of a custom
> > > section they are.  
> > 
> > Oh, that makes more sense. The SECTION stuff and custom sections was
> > confusing me. I would prefer just to drop all the LINUX_SECTION naming
> > and make it match the functionality you're using. For example:
> > 
> > +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> > +
> >  /* mutex to protect coming/going of the the jump_label table */
> >  static DEFINE_MUTEX(jump_label_mutex);
> >  
> > @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key *key,
> >  
> >  void __init jump_label_init(void)
> >  {
> > -   struct jump_entry *iter_start = __start___jump_table;
> > -   struct jump_entry *iter_stop = __stop___jump_table;
> > struct static_key *key = NULL;
> > struct jump_entry *iter;
> >  
> > @@ -292,9 +293,10 @@ void __init jump_label_init(void)
> > return;
> >  
> > jump_label_lock();
> > -   jump_label_sort_entries(iter_start, iter_stop);
> > +   jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> > +   LINUX_SECTION_END(__jump_table));
> > 
> > Now I think this is a fine abstraction to have.  
> 
> OK will keep this one.
> 
> > I think it would look
> > even cleaner if you had:
> > 
> > LINKTABLE_START(__jump_table)
> > LINKTABLE_END(__jump_table)
> >
> > Then do we need to even have the LINUX_SECTION middle man at all?  
> 
> Ah, thing is we use this for both linktables and section ranges.
> Or do we want macros for both that do the same thing ?

I think it would make the code using it more readable.

Thanks,
Nick

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-25 Thread Luis R. Rodriguez 
On Thu, Aug 25, 2016 at 12:06:33PM +1000, Nicholas Piggin wrote:
> On Wed, 24 Aug 2016 22:12:53 +0200
> "Luis R. Rodriguez"  wrote:
> > But:
> > 
> > git grep SECTION_TEXT works as expected immediately.
> > 
> > I guess its a matter of perspective.
> > 
> > > They are also
> > > the names you'll be grepping for when you look at disassembly.  
> > 
> > Sure but if you're grepping asm, you very likely know what to look for.
> 
> After you have gone through the extra layer of naming indirection
> to work out what it is. I'm still not sold on the name indirection
> and hiding wildcards. Not just for asm grepping, but I don't think
> it's a negative thing for devs working on the linker to know what
> actual section names and commands are being used, as much as possible.

OK lets see what it looks like after dropping them. Will try that.

> > The idea was to add helpers to do the globbing more easily.
> > 
> > The glob for sections now documented   is SECTION_ALL()
> > The glob that is range specificis SECTION_RNG_ALL()
> > The glob that is linker table specific is SECTION_TBL_ALL()
> 
> I still don't see this is better than
> 
> .text*
> .text.*
> .text.range.*
> .text.table.*
> etc.

OK will drop it.

> > How about:
> > 
> > At the top just use "Linux sections helpers"
> > 
> > Then:
> > 
> > /**
> >  * DOC: Introduction
> >  *
> >  * We document below a dedicated set of helpers used in Linux to make 
> > sections
> >  * defined in the Linux linker script accessible in C code in a generic 
> > form and 
> >  * and provide certain attributes about them.
> >  */
> > 
> > > I just can't work out what exactly is a
> > > "custom Linux section", and what DECLARE_LINUX_SECTION(), for example, 
> > > actaully
> > > gives you.  
> > 
> > Its a way to replace the:
> > 
> > extern char foo[], foo__end[];
> > 
> > So this provides a generalized form to use declarations used in C code to 
> > make
> > the linker script start and end symbols from esctions accessible in C code. 
> > Since
> > DEFINE_SECTION_RANGE() and DEFINE_LINKTABLE() macros use this, then the
> > DECLARE_LINUX_SECTION() is only needed if you need access to these symbols 
> > in C
> > code outside of the one that is defining and mainly in charge of managing 
> > the
> > section. We provide DECLARE_*() helpers for section ranges and linker tables
> > though so those can be used instead to help annotate the type of a custom
> > section they are.
> 
> Oh, that makes more sense. The SECTION stuff and custom sections was
> confusing me. I would prefer just to drop all the LINUX_SECTION naming
> and make it match the functionality you're using. For example:
> 
> +DEFINE_LINKTABLE(struct jump_entry, __jump_table);
> +
>  /* mutex to protect coming/going of the the jump_label table */
>  static DEFINE_MUTEX(jump_label_mutex);
>  
> @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key *key,
>  
>  void __init jump_label_init(void)
>  {
> - struct jump_entry *iter_start = __start___jump_table;
> - struct jump_entry *iter_stop = __stop___jump_table;
>   struct static_key *key = NULL;
>   struct jump_entry *iter;
>  
> @@ -292,9 +293,10 @@ void __init jump_label_init(void)
>   return;
>  
>   jump_label_lock();
> - jump_label_sort_entries(iter_start, iter_stop);
> + jump_label_sort_entries(LINUX_SECTION_START(__jump_table),
> + LINUX_SECTION_END(__jump_table));
> 
> Now I think this is a fine abstraction to have.

OK will keep this one.

> I think it would look
> even cleaner if you had:
> 
> LINKTABLE_START(__jump_table)
> LINKTABLE_END(__jump_table)
>
> Then do we need to even have the LINUX_SECTION middle man at all?

Ah, thing is we use this for both linktables and section ranges.
Or do we want macros for both that do the same thing ?

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-24 Thread Nicholas Piggin 
On Wed, 24 Aug 2016 22:12:53 +0200
"Luis R. Rodriguez"  wrote:

> On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote:
> > On Tue, 23 Aug 2016 19:33:06 +0200
> > "Luis R. Rodriguez"  wrote:
> >   
> > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:  
> > > > On Fri, 19 Aug 2016 14:34:02 -0700
> > > > mcg...@kernel.org wrote:
> > > > > +/**
> > > > > + * DOC: Standard ELF section use in Linux
> > > > > + *
> > > > > + * Linux makes use of the standard ELF sections, this sections 
> > > > > documents
> > > > > + * these.
> > > > > + */
> > > > > +
> > > > > +/**
> > > > > + * DOC: SECTION_RODATA
> > > > > + *
> > > > > + * Macro name for code which must be protected from write access, 
> > > > > read only
> > > > > + * data.
> > > > > + */
> > > > > +#define SECTION_RODATA   .rodata
> > > > 
> > > > These, for example. The exact name of the section is important in linker
> > > > scripts and asm, so I can't see the benefit of hiding it. I could be
> > > > missing the bigger picture.
> > > 
> > > There's two goals by using a macro for these core names. One is to allow 
> > > us
> > > to easily aggregate documentation in central place for each, the second is
> > > to then provide more easily grep'able helpers so we can use them when 
> > > devising
> > > extensions or using them in extensions which further customize the 
> > > sections
> > > in the kernel.  
> 
> Just thought of more more justification I had forgotten. I cover it below.
> 
> > Documentation is good, but not necessary to have the extra name 
> > indirection.  
> 
> Fair point.
> 
> > Sections tend (not always, but it would be nice if they did) to follow the
> > .name convention, which makes them reasonably easy to grep for.  
> 
> git grep .text  doesn't work but that is typically expected...
> git grep \.text doesn't work as expected
> 
> Ah finally:
> 
> git grep "\.text" seems to work. But WTF.

This is simply how grep works though.


> But:
> 
> git grep SECTION_TEXT works as expected immediately.
> 
> I guess its a matter of perspective.
> 
> > They are also
> > the names you'll be grepping for when you look at disassembly.  
> 
> Sure but if you're grepping asm, you very likely know what to look for.

After you have gone through the extra layer of naming indirection
to work out what it is. I'm still not sold on the name indirection
and hiding wildcards. Not just for asm grepping, but I don't think
it's a negative thing for devs working on the linker to know what
actual section names and commands are being used, as much as possible.


> > > > > +/**
> > > > > + * DOC: SECTION_TEXT
> > > > > + *
> > > > > + * Macro name used to annotate code (functions) used during regular
> > > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > > > > + * section also allows for execution.
> > > > > + *
> > > > > + */
> > > > > +#define SECTION_TEXT .text
> > > > 
> > > > I can't see how these comments are right. .rodata doesn't seem like it
> > > > should be combined with .text, and is not currently on powerpc. I think
> > > > it's for data, not code.
> > > 
> > > On x86 and powerpc .rodata follows .text.  
> > 
> > But follows is not the same as combined.  
> 
> True and as I confirmed below, on PowerPC this is certainly not true.

OK.


> > And together with the comment that RODATA is for code (which is wrong, it's 
> > data),  
> 
> Where did I have that? If you refer to the above SECTION_TEXT documentation, 
> it
> refers to SECTION_TEXT being for code, but the goal was to highlight that
> SECTION_TEXT is for execution, while SECTION_RODATA was for data. This
> certainly can use some love though, thanks, will just drop the SECTION_RODATA
> reference *or* properly explain the whole thing below.

+/**
+ * DOC: SECTION_RODATA
+ *
+ * Macro name for code which must be protected from write access, read only
+ * data.
+ */
+#define SECTION_RODATA .rodata

This together with the "combined with .text" part confused me.


> > it make it seem like it is actually combined.  
> 
> Will fix to ensure this is understood in proper context.

Thanks.



> > > Its not intended to grab .text but rather its for helpers that provide 
> > > customizations
> > > based on a core section as base, in this case given your example it would 
> > > be used by
> > > section ranges and linker tables for .text. Both section ranges and 
> > > linker tables
> > > use postfix .something for their customizations. The SECTION_ALL() macro 
> > > then is
> > > a helper for customizations on a core section.  
> > 
> > Right, it's just that .text.* is *immediately* obvious. SECTION_ALL() is 
> > not.  
> 
> Which is why I was suggesting perhaps an alternative name.
> 
> > > If the name is misleading would SECTION_CORE_ALL() be better with some 
> > > documentation
> > > explaining this and the above goal ?  
> > 
> > I don't

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-24 Thread Luis R. Rodriguez 
On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote:
> On Tue, 23 Aug 2016 19:33:06 +0200
> "Luis R. Rodriguez"  wrote:
> 
> > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:
> > > On Fri, 19 Aug 2016 14:34:02 -0700
> > > mcg...@kernel.org wrote:  
> > > > +/**
> > > > + * DOC: Standard ELF section use in Linux
> > > > + *
> > > > + * Linux makes use of the standard ELF sections, this sections 
> > > > documents
> > > > + * these.
> > > > + */
> > > > +
> > > > +/**
> > > > + * DOC: SECTION_RODATA
> > > > + *
> > > > + * Macro name for code which must be protected from write access, read 
> > > > only
> > > > + * data.
> > > > + */
> > > > +#define SECTION_RODATA .rodata  
> > > 
> > > These, for example. The exact name of the section is important in linker
> > > scripts and asm, so I can't see the benefit of hiding it. I could be
> > > missing the bigger picture.  
> > 
> > There's two goals by using a macro for these core names. One is to allow us
> > to easily aggregate documentation in central place for each, the second is
> > to then provide more easily grep'able helpers so we can use them when 
> > devising
> > extensions or using them in extensions which further customize the sections
> > in the kernel.

Just thought of more more justification I had forgotten. I cover it below.

> Documentation is good, but not necessary to have the extra name indirection.

Fair point.

> Sections tend (not always, but it would be nice if they did) to follow the
> .name convention, which makes them reasonably easy to grep for.

git grep .text  doesn't work but that is typically expected...
git grep \.text doesn't work as expected

Ah finally:

git grep "\.text" seems to work. But WTF.

But:

git grep SECTION_TEXT works as expected immediately.

I guess its a matter of perspective.

> They are also
> the names you'll be grepping for when you look at disassembly.

Sure but if you're grepping asm, you very likely know what to look for.

> > > > +/**
> > > > + * DOC: SECTION_TEXT
> > > > + *
> > > > + * Macro name used to annotate code (functions) used during regular
> > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > > > + * section also allows for execution.
> > > > + *
> > > > + */
> > > > +#define SECTION_TEXT   .text  
> > > 
> > > I can't see how these comments are right. .rodata doesn't seem like it
> > > should be combined with .text, and is not currently on powerpc. I think
> > > it's for data, not code.  
> > 
> > On x86 and powerpc .rodata follows .text.
> 
> But follows is not the same as combined.

True and as I confirmed below, on PowerPC this is certainly not true.

> And together with the comment that RODATA is for code (which is wrong, it's 
> data),

Where did I have that? If you refer to the above SECTION_TEXT documentation, it
refers to SECTION_TEXT being for code, but the goal was to highlight that
SECTION_TEXT is for execution, while SECTION_RODATA was for data. This
certainly can use some love though, thanks, will just drop the SECTION_RODATA
reference *or* properly explain the whole thing below.

> it make it seem like it is actually combined.

Will fix to ensure this is understood in proper context.

> > On power currently the comment
> > above in .rodata is:
> > 
> > /* Text, read only data and other permanent read-only sections */
> > 
> > When this was introduced however read commit 14cf11af6cf60 ("powerpc: Merge
> > enough to start building in arch/powerpc.")
> > 
> > /* Read-only sections, merged into text segment: */
> > 
> > The format and style of putting rodata after text is kept from the older
> > commits.
> > 
> > This begs the question. What the hell is this thing talking about?
> > 
> > On Linux this is done via mark_rodata_ro() on init/main.c when 
> > CONFIG_DEBUG_RODATA
> > on architectures that support it. Architectures that implement this 
> > typically use
> > issues set_memory_ro() -- on x86 a start address used is PFN_ALIGN(_text) 
> > with
> > an end address of &__end_rodata_hpage_align.
> > 
> > When architectures do not have CONFIG_DEBUG_RODATA() you end up with:
> > 
> > static inline void mark_readonly(void)  
> > 
> > {   
> > 
> > pr_warn("This architecture does not have kernel memory 
> > protection.\n"); 
> > }
> > 
> > So -- I should I clarify then in Linux we strive to have helpers adjust 
> > text and
> > rodata set to ro with memory protection implemented via mark_readonly(). 
> > Architectures
> > that do not support memory protection will lack a mark_readonly() 
> > implementation.
> 
> Right, I wasn't talking about arch implementation of how the ro
> protection is done, so much as just the comments being a bit misleading.

Sure, got it, thanks, will fix.

> > For now I figured a less controversial introduction to the

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-23 Thread Nicholas Piggin 
On Tue, 23 Aug 2016 19:33:06 +0200
"Luis R. Rodriguez"  wrote:

> On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:
> > On Fri, 19 Aug 2016 14:34:02 -0700
> > mcg...@kernel.org wrote:  
> > > +/**
> > > + * DOC: Standard ELF section use in Linux
> > > + *
> > > + * Linux makes use of the standard ELF sections, this sections documents
> > > + * these.
> > > + */
> > > +
> > > +/**
> > > + * DOC: SECTION_RODATA
> > > + *
> > > + * Macro name for code which must be protected from write access, read 
> > > only
> > > + * data.
> > > + */
> > > +#define SECTION_RODATA   .rodata  
> > 
> > These, for example. The exact name of the section is important in linker
> > scripts and asm, so I can't see the benefit of hiding it. I could be
> > missing the bigger picture.  
> 
> There's two goals by using a macro for these core names. One is to allow us
> to easily aggregate documentation in central place for each, the second is
> to then provide more easily grep'able helpers so we can use them when devising
> extensions or using them in extensions which further customize the sections
> in the kernel.

Documentation is good, but not necessary to have the extra name indirection.
Sections tend (not always, but it would be nice if they did) to follow the
.name convention, which makes them reasonably easy to grep for. They are also
the names you'll be grepping for when you look at disassembly.


> > > +/**
> > > + * DOC: SECTION_TEXT
> > > + *
> > > + * Macro name used to annotate code (functions) used during regular
> > > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > > + * section also allows for execution.
> > > + *
> > > + */
> > > +#define SECTION_TEXT .text  
> > 
> > I can't see how these comments are right. .rodata doesn't seem like it
> > should be combined with .text, and is not currently on powerpc. I think
> > it's for data, not code.  
> 
> On x86 and powerpc .rodata follows .text.

But follows is not the same as combined. And together with the comment that
RODATA is for code (which is wrong, it's data), it make it seem like it
is actually combined.


> On power currently the comment
> above in .rodata is:
> 
> /* Text, read only data and other permanent read-only sections */
> 
> When this was introduced however read commit 14cf11af6cf60 ("powerpc: Merge
> enough to start building in arch/powerpc.")
> 
> /* Read-only sections, merged into text segment: */
> 
> The format and style of putting rodata after text is kept from the older
> commits.
> 
> This begs the question. What the hell is this thing talking about?
> 
> On Linux this is done via mark_rodata_ro() on init/main.c when 
> CONFIG_DEBUG_RODATA
> on architectures that support it. Architectures that implement this typically 
> use
> issues set_memory_ro() -- on x86 a start address used is PFN_ALIGN(_text) with
> an end address of &__end_rodata_hpage_align.
> 
> When architectures do not have CONFIG_DEBUG_RODATA() you end up with:
> 
> static inline void mark_readonly(void)
>   
> { 
>   
> pr_warn("This architecture does not have kernel memory 
> protection.\n"); 
> }
> 
> So -- I should I clarify then in Linux we strive to have helpers adjust text 
> and
> rodata set to ro with memory protection implemented via mark_readonly(). 
> Architectures
> that do not support memory protection will lack a mark_readonly() 
> implementation.

Right, I wasn't talking about arch implementation of how the ro
protection is done, so much as just the comments being a bit misleading.


> For now I figured a less controversial introduction to the documentation as
> bland as it was above in my original patch would suffice, we can then expand 
> on
> it with something like the above. Thoughts?

I think comments are one of the key features of this patch series (or at
least this patch, I've not looked through the others so much yet). I'm no
expert on linker stuff, but I think a lot of arch maintainers aren't
necessarily either so you tend to get a lot of copy and paste without
always people knowing what exactly is happening. It would be really good
to have some longer explanations and justifications/examples IMO. So I
don't think that would be controversial if you wanted to expand on it.


> > > +/*
> > > + * These section _ALL() helpers are for use on linker scripts and helpers
> > > + */
> > > +#define SECTION_ALL(__section)   
> > > \
> > > + __section##.*  
> > 
> > This is another example. We know what .text.* does in the linker scripts
> > -- it's self documenting. But SECTION_ALL(.text)? I'm not sure that's an
> > improvement. Actually I saw it in the linker script changes and had to
> > come find the definition because I was a bit mislead:
> > 
> > SECTION_ALL(.text)
> > 
> > Initially I would expect this to

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-23 Thread Luis R. Rodriguez 
On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:
> On Fri, 19 Aug 2016 14:34:02 -0700
> mcg...@kernel.org wrote:
> > +/**
> > + * DOC: Standard ELF section use in Linux
> > + *
> > + * Linux makes use of the standard ELF sections, this sections documents
> > + * these.
> > + */
> > +
> > +/**
> > + * DOC: SECTION_RODATA
> > + *
> > + * Macro name for code which must be protected from write access, read only
> > + * data.
> > + */
> > +#define SECTION_RODATA .rodata
> 
> These, for example. The exact name of the section is important in linker
> scripts and asm, so I can't see the benefit of hiding it. I could be
> missing the bigger picture.

There's two goals by using a macro for these core names. One is to allow us
to easily aggregate documentation in central place for each, the second is
to then provide more easily grep'able helpers so we can use them when devising
extensions or using them in extensions which further customize the sections
in the kernel.

> > +/**
> > + * DOC: SECTION_TEXT
> > + *
> > + * Macro name used to annotate code (functions) used during regular
> > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > + * section also allows for execution.
> > + *
> > + */
> > +#define SECTION_TEXT   .text
> 
> I can't see how these comments are right. .rodata doesn't seem like it
> should be combined with .text, and is not currently on powerpc. I think
> it's for data, not code.

On x86 and powerpc .rodata follows .text. On power currently the comment
above in .rodata is:

/* Text, read only data and other permanent read-only sections */

When this was introduced however read commit 14cf11af6cf60 ("powerpc: Merge
enough to start building in arch/powerpc.")

/* Read-only sections, merged into text segment: */

The format and style of putting rodata after text is kept from the older
commits.

This begs the question. What the hell is this thing talking about?

On Linux this is done via mark_rodata_ro() on init/main.c when 
CONFIG_DEBUG_RODATA
on architectures that support it. Architectures that implement this typically 
use
issues set_memory_ro() -- on x86 a start address used is PFN_ALIGN(_text) with
an end address of &__end_rodata_hpage_align.

When architectures do not have CONFIG_DEBUG_RODATA() you end up with:

static inline void mark_readonly(void)  
{   
pr_warn("This architecture does not have kernel memory protection.\n"); 
}

So -- I should I clarify then in Linux we strive to have helpers adjust text and
rodata set to ro with memory protection implemented via mark_readonly(). 
Architectures
that do not support memory protection will lack a mark_readonly() 
implementation.

For now I figured a less controversial introduction to the documentation as
bland as it was above in my original patch would suffice, we can then expand on
it with something like the above. Thoughts?

> > +/*
> > + * These section _ALL() helpers are for use on linker scripts and helpers
> > + */
> > +#define SECTION_ALL(__section) 
> > \
> > +   __section##.*
> 
> This is another example. We know what .text.* does in the linker scripts
> -- it's self documenting. But SECTION_ALL(.text)? I'm not sure that's an
> improvement. Actually I saw it in the linker script changes and had to
> come find the definition because I was a bit mislead:
> 
> SECTION_ALL(.text)
> 
> Initially I would expect this to be
> 
> .text*
> 
> Not
> 
> .text.*
> 
> The latter does not grab the .text section!

Its not intended to grab .text but rather its for helpers that provide 
customizations
based on a core section as base, in this case given your example it would be 
used by
section ranges and linker tables for .text. Both section ranges and linker 
tables
use postfix .something for their customizations. The SECTION_ALL() macro then is
a helper for customizations on a core section.

If the name is misleading would SECTION_CORE_ALL() be better with some 
documentation
explaining this and the above goal ?

> > +/*
> > + * As per gcc's documentation a common asm separator is a new line followed
> > + * by tab [0], it however seems possible to also just use a newline as its
> > + * the most commonly empirically observed semantic and folks seem to agree
> > + * this even works on S390. In case your architecture disagrees you may
> > + * override this and define your own and keep the rest of the macros.
> > + *
> > + * [0] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
> > + */
> > +# ifndef ASM_CMD_SEP
> > +#  define ASM_CMD_SEP  "\n"
> > +# endif
> 
> This does not seem like it belongs here. The name is fairly ugly too.

Help me bikeshed, any name suggestions?

> I guess something might be needed like this when dealing with generic
> as directives common to all architectures, though.

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-22 Thread Nicholas Piggin 
On Fri, 19 Aug 2016 14:34:02 -0700
mcg...@kernel.org wrote:

> From: "Luis R. Rodriguez" 
> 
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
> documentation in a central place and provide helpers to
> build custom Linux sections.
> 
> This also generalizes sections code to enable avoiding
> modifying the linker scripts when we want to add new
> custom Linux sections. In order to make this generally
> useful we need to ensure all architectures can make use of
> core section helpers but that they can also override should
> this be needed. Instead of relying on section.h this adds
> a sections-core.h since this will be targetted to be safe
> to be used on asm code, linker scripts and C code.

Hi Luis,

The linker stuff in the kernel definitely needs someone to take care
of it, so it's good to see some effort to clean up and generalize some
of it.

Not all your patches seem to depend on each other, so it might be good
to push some of the cleanups through first. And some of these core
patches could go in bit by bit if necessary.

On this specific patch: while the as and ld sections syntax and
semantics are pretty ugly and esoteric, I question how much of this is
actually an improvement. Some of it seems to just be wrapping one name
with another, or hiding some behaviour in a maybe not intuitive way.


> +/**
> + * DOC: Standard ELF section use in Linux
> + *
> + * Linux makes use of the standard ELF sections, this sections documents
> + * these.
> + */
> +
> +/**
> + * DOC: SECTION_RODATA
> + *
> + * Macro name for code which must be protected from write access, read only
> + * data.
> + */
> +#define SECTION_RODATA   .rodata

These, for example. The exact name of the section is important in linker
scripts and asm, so I can't see the benefit of hiding it. I could be
missing the bigger picture.


> +/**
> + * DOC: SECTION_TEXT
> + *
> + * Macro name used to annotate code (functions) used during regular
> + * kernel run time. This is combined with `SECTION_RODATA`, only this
> + * section also allows for execution.
> + *
> + */
> +#define SECTION_TEXT .text

I can't see how these comments are right. .rodata doesn't seem like it
should be combined with .text, and is not currently on powerpc. I think
it's for data, not code.


> +/*
> + * These section _ALL() helpers are for use on linker scripts and helpers
> + */
> +#define SECTION_ALL(__section)   
> \
> + __section##.*

This is another example. We know what .text.* does in the linker scripts
-- it's self documenting. But SECTION_ALL(.text)? I'm not sure that's an
improvement. Actually I saw it in the linker script changes and had to
come find the definition because I was a bit mislead:

SECTION_ALL(.text)

Initially I would expect this to be

.text*

Not

.text.*

The latter does not grab the .text section!


> +/*
> + * As per gcc's documentation a common asm separator is a new line followed
> + * by tab [0], it however seems possible to also just use a newline as its
> + * the most commonly empirically observed semantic and folks seem to agree
> + * this even works on S390. In case your architecture disagrees you may
> + * override this and define your own and keep the rest of the macros.
> + *
> + * [0] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
> + */
> +# ifndef ASM_CMD_SEP
> +#  define ASM_CMD_SEP"\n"
> +# endif

This does not seem like it belongs here. The name is fairly ugly too.
I guess something might be needed like this when dealing with generic
as directives common to all architectures, though. I would say
include/asm-generic/asm.h should be a better place.


> diff --git a/include/linux/sections.h b/include/linux/sections.h
> new file mode 100644
> index ..f21c6ee88ded
> --- /dev/null
> +++ b/include/linux/sections.h
> @@ -0,0 +1,111 @@
> +#ifndef _LINUX_SECTIONS_H
> +#define _LINUX_SECTIONS_H
> +/*
> + * Linux de-facto sections
> + *
> + * Copyright (C) 2016 Luis R. Rodriguez 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of copyleft-next (version 0.3.1 or later) as published
> + * at http://copyleft-next.org/.
> + */
> +
> +#include 
> +#include 
> +
> +#ifndef __ASSEMBLY__
> +
> +/**
> + * DOC: Introduction
> + *
> + * Linux defines a set of common helpers which can be used to against its use
> + * of standard or custom Linux sections, this section is dedicated to these
> + * helpers.

I'm still not quite sure what a Linux de-facto/standard/common section is
after this. Are they output sections?

I think it would be reasonable to drop the LINUX_ prefix and references to
Linux.

Thanks,
Nick

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-22 Thread Luis R. Rodriguez 
On Fri, Aug 19, 2016 at 02:47:48PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > From: "Luis R. Rodriguez" 
> >
> > +SECTION_RODATA
> > +--
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_RODATA
> > +
> > +SECTION_RODATA
> 
> Typo: should this be called SECTION_TEXT instead?

Fixed thanks.

> > +--
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_TEXT
> > +
> > +SECTION_DATA
> > +
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_DATA
> 
> Missing from this list are things like the __read_mostly
> (".data..read_mostly") and __ro_after_init (".data..ro_after_init")
> sections. Should those be included too, or are you only doing the "top
> level" sections?

I'm doing top level right now just to start off and get the
bikeshedding out of the way. We can add more with more time
or as we port more things or as the need arises.

  Luis

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-19 Thread Kees Cook 
On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> From: "Luis R. Rodriguez" 
>
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
> documentation in a central place and provide helpers to
> build custom Linux sections.
>
> This also generalizes sections code to enable avoiding
> modifying the linker scripts when we want to add new
> custom Linux sections. In order to make this generally
> useful we need to ensure all architectures can make use of
> core section helpers but that they can also override should
> this be needed. Instead of relying on section.h this adds
> a sections-core.h since this will be targetted to be safe
> to be used on asm code, linker scripts and C code.
>
> v4:
>
> o Port to shiny new sphinx documentation format
>
> o fix a unicore32 build, turns out this actually fixes unicore32
>   defconfig builds which were failing for a long while. unicore32
>   does not seem to grok well the type passed on a section declaration,
>   this ignores it.
>
> o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
>   this was causing final linker issues with blackfin -- this is
>   a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
>   being metatag. metatag is not supported on 0-day so I cannot confirm
>   compilation there.
>
> o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()
>
> o Since SECTION_CORE() is defined for linker script and C code, share
>   the same helper and just use a __stringify() for the C code as is done
>   for the other C helpers.
>
> o move generic sections to asm-generic/section-core.h instead.
>   PowerPC compilation blows up if asm/jump_labels.h gets
>   section.h included, fixing this is not in any way easy.
>   The list of issues are endless. Moving new data to a new
>   simple file resolves this.
>
> o since things are now in asm-generic/section-core.h the
>   guard changes on asm-generic/sections.h and each architecture
>   sections.h are no longer needed
>
> o Give generic sections some maintainer love, that change is
>   Acked-by Arnd Bergmann, Josh and hpa.
>
> o A few checkpatch.pl style fixes
>
> o As suggested by James Hogan use generic-y to copy generic
>   header files on architectures that do not have a sections.h
>   instead of writing a simple file only to include the generic one.
>
> v3:
>
> o add missing sections.h for architectures that did not
>   have it
>
> o move generic sections to asm-generic/sections.h
>
> o add generic asm helpers section_type(), section_type_asmtype(),
>   push_section_type() -- these helpers enable easy use for
>   for later declaring and using of custom linux sections using
>   more standard APIs in both C code, asm code (C asm calls, or
>   asm files), enabling future standardized section types to
>   be more immediately accessible to asm code, not just C code.
>   Note for ASM_CMD_SEP we use by default "\n", architectures needed
>   to override can do so on their own sections.h prior to inclusion
>   of asm-generic/sections.h
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/index.rst   |   1 +
>  Documentation/sections/conf.py|   4 +
>  Documentation/sections/index.rst  |  11 +
>  Documentation/sections/section-core.rst   | 153 ++
>  MAINTAINERS   |  14 ++
>  arch/alpha/include/asm/Kbuild |   1 +
>  arch/arc/include/asm/Kbuild   |   1 +
>  arch/arm/include/asm/Kbuild   |   1 +
>  arch/arm64/include/asm/Kbuild |   1 +
>  arch/avr32/include/asm/Kbuild |   1 +
>  arch/blackfin/include/asm/Kbuild  |   1 +
>  arch/c6x/include/asm/Kbuild   |   1 +
>  arch/cris/include/asm/Kbuild  |   1 +
>  arch/frv/include/asm/Kbuild   |   1 +
>  arch/h8300/include/asm/Kbuild |   1 +
>  arch/hexagon/include/asm/Kbuild   |   1 +
>  arch/ia64/include/asm/Kbuild  |   1 +
>  arch/m32r/include/asm/Kbuild  |   1 +
>  arch/m68k/include/asm/Kbuild  |   1 +
>  arch/metag/include/asm/Kbuild |   1 +
>  arch/microblaze/include/asm/Kbuild|   1 +
>  arch/mips/include/asm/Kbuild  |   1 +
>  arch/mn10300/include/asm/Kbuild   |   1 +
>  arch/nios2/include/asm/Kbuild |   1 +
>  arch/openrisc/include/asm/Kbuild  |   1 +
>  arch/parisc/include/asm/Kbuild|   1 +
>  arch/powerpc/include/asm/Kbuild   |   1 +
>  arch/s390/include/asm/Kbuild  |   1 +
>  arch/score/include/asm/Kbuild |   1 +
>  arch/sh/include/asm/Kbuild|   1 +
>  arch/sparc/include/asm/Kbuild |   1 +
>  arch/tile/include/asm/Kbuild  |   1 +
>  arch/um/include/asm/Kbuild|   1 +
>  arch/unicore32/include/asm/section-core.h |  19 ++
>

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-19 Thread mcgrof 
From: "Luis R. Rodriguez" 

Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place and provide helpers to
build custom Linux sections.

This also generalizes sections code to enable avoiding
modifying the linker scripts when we want to add new
custom Linux sections. In order to make this generally
useful we need to ensure all architectures can make use of
core section helpers but that they can also override should
this be needed. Instead of relying on section.h this adds
a sections-core.h since this will be targetted to be safe
to be used on asm code, linker scripts and C code.

v4:

o Port to shiny new sphinx documentation format

o fix a unicore32 build, turns out this actually fixes unicore32
  defconfig builds which were failing for a long while. unicore32
  does not seem to grok well the type passed on a section declaration,
  this ignores it.

o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
  this was causing final linker issues with blackfin -- this is
  a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
  being metatag. metatag is not supported on 0-day so I cannot confirm
  compilation there.

o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()

o Since SECTION_CORE() is defined for linker script and C code, share
  the same helper and just use a __stringify() for the C code as is done
  for the other C helpers.

o move generic sections to asm-generic/section-core.h instead.
  PowerPC compilation blows up if asm/jump_labels.h gets
  section.h included, fixing this is not in any way easy.
  The list of issues are endless. Moving new data to a new
  simple file resolves this.

o since things are now in asm-generic/section-core.h the
  guard changes on asm-generic/sections.h and each architecture
  sections.h are no longer needed

o Give generic sections some maintainer love, that change is
  Acked-by Arnd Bergmann, Josh and hpa.

o A few checkpatch.pl style fixes

o As suggested by James Hogan use generic-y to copy generic
  header files on architectures that do not have a sections.h
  instead of writing a simple file only to include the generic one.

v3:

o add missing sections.h for architectures that did not
  have it

o move generic sections to asm-generic/sections.h

o add generic asm helpers section_type(), section_type_asmtype(),
  push_section_type() -- these helpers enable easy use for
  for later declaring and using of custom linux sections using
  more standard APIs in both C code, asm code (C asm calls, or
  asm files), enabling future standardized section types to
  be more immediately accessible to asm code, not just C code.
  Note for ASM_CMD_SEP we use by default "\n", architectures needed
  to override can do so on their own sections.h prior to inclusion
  of asm-generic/sections.h

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/index.rst   |   1 +
 Documentation/sections/conf.py|   4 +
 Documentation/sections/index.rst  |  11 +
 Documentation/sections/section-core.rst   | 153 ++
 MAINTAINERS   |  14 ++
 arch/alpha/include/asm/Kbuild |   1 +
 arch/arc/include/asm/Kbuild   |   1 +
 arch/arm/include/asm/Kbuild   |   1 +
 arch/arm64/include/asm/Kbuild |   1 +
 arch/avr32/include/asm/Kbuild |   1 +
 arch/blackfin/include/asm/Kbuild  |   1 +
 arch/c6x/include/asm/Kbuild   |   1 +
 arch/cris/include/asm/Kbuild  |   1 +
 arch/frv/include/asm/Kbuild   |   1 +
 arch/h8300/include/asm/Kbuild |   1 +
 arch/hexagon/include/asm/Kbuild   |   1 +
 arch/ia64/include/asm/Kbuild  |   1 +
 arch/m32r/include/asm/Kbuild  |   1 +
 arch/m68k/include/asm/Kbuild  |   1 +
 arch/metag/include/asm/Kbuild |   1 +
 arch/microblaze/include/asm/Kbuild|   1 +
 arch/mips/include/asm/Kbuild  |   1 +
 arch/mn10300/include/asm/Kbuild   |   1 +
 arch/nios2/include/asm/Kbuild |   1 +
 arch/openrisc/include/asm/Kbuild  |   1 +
 arch/parisc/include/asm/Kbuild|   1 +
 arch/powerpc/include/asm/Kbuild   |   1 +
 arch/s390/include/asm/Kbuild  |   1 +
 arch/score/include/asm/Kbuild |   1 +
 arch/sh/include/asm/Kbuild|   1 +
 arch/sparc/include/asm/Kbuild |   1 +
 arch/tile/include/asm/Kbuild  |   1 +
 arch/um/include/asm/Kbuild|   1 +
 arch/unicore32/include/asm/section-core.h |  19 ++
 arch/x86/include/asm/Kbuild   |   1 +
 arch/xtensa/include/asm/Kbuild|   1 +
 include/asm-generic/section-core.h| 341 ++
 include/asm-generic/sections.h|   2 +
 include/asm-generic/vmlinux.lds.h

[Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

2016-08-19 Thread mcgrof 
From: "Luis R. Rodriguez" 

Linux makes extensive use of custom ELF header sections,
documentation for these are well scatterred. Unify this
documentation in a central place and provide helpers to
build custom Linux sections.

This also generalizes sections code to enable avoiding
modifying the linker scripts when we want to add new
custom Linux sections. In order to make this generally
useful we need to ensure all architectures can make use of
core section helpers but that they can also override should
this be needed. Instead of relying on section.h this adds
a sections-core.h since this will be targetted to be safe
to be used on asm code, linker scripts and C code.

v4:

o Port to shiny new sphinx documentation format

o fix a unicore32 build, turns out this actually fixes unicore32
  defconfig builds which were failing for a long while. unicore32
  does not seem to grok well the type passed on a section declaration,
  this ignores it.

o Use VMLINUX_SYMBOL() in more user symbols (extern C code), not doing
  this was causing final linker issues with blackfin -- this is
  a CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX=y architecture. The other one
  being metatag. metatag is not supported on 0-day so I cannot confirm
  compilation there.

o Added SECTION_CORE() for C code, used later by __LINUX_RANGE()

o Since SECTION_CORE() is defined for linker script and C code, share
  the same helper and just use a __stringify() for the C code as is done
  for the other C helpers.

o move generic sections to asm-generic/section-core.h instead.
  PowerPC compilation blows up if asm/jump_labels.h gets
  section.h included, fixing this is not in any way easy.
  The list of issues are endless. Moving new data to a new
  simple file resolves this.

o since things are now in asm-generic/section-core.h the
  guard changes on asm-generic/sections.h and each architecture
  sections.h are no longer needed

o Give generic sections some maintainer love, that change is
  Acked-by Arnd Bergmann, Josh and hpa.

o A few checkpatch.pl style fixes

o As suggested by James Hogan use generic-y to copy generic
  header files on architectures that do not have a sections.h
  instead of writing a simple file only to include the generic one.

v3:

o add missing sections.h for architectures that did not
  have it

o move generic sections to asm-generic/sections.h

o add generic asm helpers section_type(), section_type_asmtype(),
  push_section_type() -- these helpers enable easy use for
  for later declaring and using of custom linux sections using
  more standard APIs in both C code, asm code (C asm calls, or
  asm files), enabling future standardized section types to
  be more immediately accessible to asm code, not just C code.
  Note for ASM_CMD_SEP we use by default "\n", architectures needed
  to override can do so on their own sections.h prior to inclusion
  of asm-generic/sections.h

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/index.rst   |   1 +
 Documentation/sections/conf.py|   4 +
 Documentation/sections/index.rst  |  11 +
 Documentation/sections/section-core.rst   | 153 ++
 MAINTAINERS   |  14 ++
 arch/alpha/include/asm/Kbuild |   1 +
 arch/arc/include/asm/Kbuild   |   1 +
 arch/arm/include/asm/Kbuild   |   1 +
 arch/arm64/include/asm/Kbuild |   1 +
 arch/avr32/include/asm/Kbuild |   1 +
 arch/blackfin/include/asm/Kbuild  |   1 +
 arch/c6x/include/asm/Kbuild   |   1 +
 arch/cris/include/asm/Kbuild  |   1 +
 arch/frv/include/asm/Kbuild   |   1 +
 arch/h8300/include/asm/Kbuild |   1 +
 arch/hexagon/include/asm/Kbuild   |   1 +
 arch/ia64/include/asm/Kbuild  |   1 +
 arch/m32r/include/asm/Kbuild  |   1 +
 arch/m68k/include/asm/Kbuild  |   1 +
 arch/metag/include/asm/Kbuild |   1 +
 arch/microblaze/include/asm/Kbuild|   1 +
 arch/mips/include/asm/Kbuild  |   1 +
 arch/mn10300/include/asm/Kbuild   |   1 +
 arch/nios2/include/asm/Kbuild |   1 +
 arch/openrisc/include/asm/Kbuild  |   1 +
 arch/parisc/include/asm/Kbuild|   1 +
 arch/powerpc/include/asm/Kbuild   |   1 +
 arch/s390/include/asm/Kbuild  |   1 +
 arch/score/include/asm/Kbuild |   1 +
 arch/sh/include/asm/Kbuild|   1 +
 arch/sparc/include/asm/Kbuild |   1 +
 arch/tile/include/asm/Kbuild  |   1 +
 arch/um/include/asm/Kbuild|   1 +
 arch/unicore32/include/asm/section-core.h |  19 ++
 arch/x86/include/asm/Kbuild   |   1 +
 arch/xtensa/include/asm/Kbuild|   1 +
 include/asm-generic/section-core.h| 341 ++
 include/asm-generic/sections.h|   2 +
 include/asm-generic/vmlinux.lds.h