| Message ID | 1471642454-5679-5-git-send-email-mcgrof@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 19 Aug 2016 14:34:02 -0700 mcgrof@kernel.org wrote: > From: "Luis R. Rodriguez" <mcgrof@kernel.org> > > 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 000000000000..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 <mcgrof@kernel.org> > + * > + * 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 <asm/section-core.h> > +#include <linux/export.h> > + > +#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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > On Fri, 19 Aug 2016 14:34:02 -0700 > mcgrof@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. Indeed, it actually seems we don't have much in this area, so this is small baby step in that direction. > I would say include/asm-generic/asm.h should be a better place. I thought about this -- I'd be adding a new asm-generic/asm.h -- are folks OK with that right now? Or should we do that as a secondary step ? I preferred to do this as a secondary step as this series is long enough already and there is quite a bit that can be dumped in a common asm-generic/asm.h, a few thoughts on this already: o x86's asm/asm.h's use of __ASM_FORM() and include/linux/stringify.h share some traits which deserve possible consideration / rebranding. o Since C asm() just wrap things in strings defining a core set of helpers for a task seems justifiable, so for example we have __set_section_core_type(). Raw asm code then would use __set_section_core_type() directly and C asm() would just __stringify() it. I figured a bit of bikeshedding would be possible here, so I decided to leave this for a later set of patches. But indeed, I agree with you. If we want this meshed out now.. let me know and lets bikeshed away... > > diff --git a/include/linux/sections.h b/include/linux/sections.h > > new file mode 100644 > > index 000000000000..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 <mcgrof@kernel.org> > > + * > > + * 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 <asm/section-core.h> > > +#include <linux/export.h> > > + > > +#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? We have ELF standard sections, and we have then sections which Linux has introduced over the years which are now just known to be expected part of Linux, such as init stuff which we free after boot. The combination of the ELF standard sections and series of expected sections in Linux across all architectures is what this refers to as Linux de-facto/standard/common sections. The header file is intended to document these, step by step, and also provide helpers which allow further customizations based on these sections. > > I think it would be reasonable to drop the LINUX_ prefix and references to > Linux. I'm not so sure about this for section stuff -- are we certain we won't ever clash with some built in compiler things? I'm fine to drop the prefix -- bikeshedding -- will drop it for the next series unless I hear otherwise... Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 23 Aug 2016 19:33:06 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > > On Fri, 19 Aug 2016 14:34:02 -0700 > > mcgrof@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 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. Right, it's just that .text.* is *immediately* obvious. SECTION_ALL() is not. > If the name is misleading would SECTION_CORE_ALL() be better with some documentation > explaining this and the above goal ? I don't know... not to be glib, but .section.* would be better and not require documentation. CORE does not really add anything as far as I can see. Other types of .text including ones which are automatically generated by the compiler, for better or worse, are .text.x sections too. I would like to see more standardisation of naming convention -- some sections start with .., some start with no dots, some use . to separate logical "subsections", others use underscores or something else. I just don't see it would be a problem to simply use the raw names and linker wildcards for it. > > > +/* > > > + * 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? BTW, I'm not trying to bikeshed :) This doesn't affect the value of your patch at all, it was just an offhand thing I saw. > > > I guess something might be needed like this when dealing with generic > > as directives common to all architectures, though. > > Indeed, it actually seems we don't have much in this area, so this is small > baby step in that direction. > > > I would say include/asm-generic/asm.h should be a better place. > > I thought about this -- I'd be adding a new asm-generic/asm.h -- are folks OK > with that right now? Or should we do that as a secondary step ? I preferred to > do this as a secondary step as this series is long enough already and there is > quite a bit that can be dumped in a common asm-generic/asm.h, a few thoughts > on this already: > > o x86's asm/asm.h's use of __ASM_FORM() and include/linux/stringify.h share > some traits which deserve possible consideration / rebranding. > o Since C asm() just wrap things in strings defining a core set of > helpers for a task seems justifiable, so for example we have > __set_section_core_type(). Raw asm code then would use __set_section_core_type() > directly and C asm() would just __stringify() it. > > I figured a bit of bikeshedding would be possible here, so I decided to leave > this for a later set of patches. But indeed, I agree with you. If we want > this meshed out now.. let me know and lets bikeshed away... It's fine, I don't mind too much. I think asm-generic/asm.h should be fine for generic asm'isms though. Or assembler.h to match compiler.h. > > > diff --git a/include/linux/sections.h b/include/linux/sections.h > > > new file mode 100644 > > > index 000000000000..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 <mcgrof@kernel.org> > > > + * > > > + * 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 <asm/section-core.h> > > > +#include <linux/export.h> > > > + > > > +#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? > > We have ELF standard sections, and we have then sections which Linux has introduced > over the years which are now just known to be expected part of Linux, such as init > stuff which we free after boot. The combination of the ELF standard sections and > series of expected sections in Linux across all architectures is what this refers > to as Linux de-facto/standard/common sections. The header file is intended to > document these, step by step, and also provide helpers which allow further > customizations based on these sections. Well but your macros are not linker sections. They are "Linux sections", which appear to give you a start and end symbol name, but does not direct the linker to create a specific output section. I just can't work out what exactly is a "custom Linux section", and what DECLARE_LINUX_SECTION(), for example, actaully gives you. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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" <mcgrof@kernel.org> wrote: > > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > > > On Fri, 19 Aug 2016 14:34:02 -0700 > > > mcgrof@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 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). Definitely -- the goal was to give us central place to document some of this obscure dark magic only a few witches and warlocks tend to be aware of. > 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. :) Yes indeed, the little crusade over the PowerPC linker script comments on .text and ro data is an example of how easily things can be misleading. > 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. Sure, but what I was trying to say above is I'd rather have the basic layout of the documentation finalized before we start getting into very specific detailed elaborate details on some of these things. For instance we still haven't decided if we wanted SECTION_TEXT or just require everyone to hard code in .text in every place a user wants to use .text sections. I'd rather settle that before trying to document mark_readonly(). > > > > +/* > > > > + * 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. > > 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 know... not to be glib, but .section.* would be better and not require > documentation. Well consider the issues below for a second... and keep in mind with linker tables we are about to open the prospect to add more things into the kernel's sections more easily than before. > CORE does not really add anything as far as I can see. Other types of .text including > ones which are automatically generated by the compiler, for better or worse, are > .text.x sections too. Actually, sorry, in this case SECTION_ALL() *was* intended for things that are not linker tables or section ranges, instead this was for globs that want to use the new section macro names, so we only use this for: *(SECTION_ALL(SECTION_RODATA)) at this time. It would seem we just did not have .text.* and friends (other section names documented here). So this is more of a reaction to provide a way to use a glob for section names if they have a macro name. 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 specific is SECTION_RNG_ALL() The glob that is linker table specific is SECTION_TBL_ALL() The only one needing SECTION_ALL() it turns out was .rodata: - *(.rodata) *(.rodata.*) \ + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ > I would like to see more standardisation of naming convention -- some sections start > with .., some start with no dots, some use . to separate logical "subsections", others > use underscores or something else. Agreed... Actually while at it -- anyone happen to know why the two dot thing started creeping up? > I just don't see it would be a problem to simply use the raw names and linker > wildcards for it. A concern here is more abuse over this if we now expose APIs to users to more easily customize sections. So let's review what the chances are. $ git grep DEFINE_SECTION_RANGE| egrep -v "tools|include|Document" kernel/kprobes.c:DEFINE_SECTION_RANGE(kprobes, SECTION_TEXT); These require the actual desired section specified. Do we want to just hide that ? Or are we OK in assuming users willing to use proper names here? For linker tables we actually provide full helpers for each section type. So we have: $ git grep DEFINE_LINKTABLE| egrep -v "tools|include|Document" drivers/base/firmware_class.c:DEFINE_LINKTABLE_RO(struct builtin_fw, builtin_fw); kernel/jump_label.c:DEFINE_LINKTABLE(struct jump_entry, __jump_table); kernel/kprobes.c:DEFINE_LINKTABLE_INIT_DATA(unsigned long, _kprobe_blacklist); lib/dynamic_debug.c:DEFINE_LINKTABLE(struct _ddebug, __verbose); So for linker tables we're safe from abuse as we provide all direct use of the section up to the implementation behind the scenes. If we're happy then with people using a proper section name for section ranges then I think we can require the full section name being spelled out. > > > > +/* > > > > + * 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? > > BTW, I'm not trying to bikeshed :) This doesn't affect the value of your > patch at all, it was just an offhand thing I saw. Just saying, if you say its ugly please help me with a different name then. > > > I guess something might be needed like this when dealing with generic > > > as directives common to all architectures, though. > > > > Indeed, it actually seems we don't have much in this area, so this is small > > baby step in that direction. > > > > > I would say include/asm-generic/asm.h should be a better place. > > > > I thought about this -- I'd be adding a new asm-generic/asm.h -- are folks OK > > with that right now? Or should we do that as a secondary step ? I preferred to > > do this as a secondary step as this series is long enough already and there is > > quite a bit that can be dumped in a common asm-generic/asm.h, a few thoughts > > on this already: > > > > o x86's asm/asm.h's use of __ASM_FORM() and include/linux/stringify.h share > > some traits which deserve possible consideration / rebranding. > > o Since C asm() just wrap things in strings defining a core set of > > helpers for a task seems justifiable, so for example we have > > __set_section_core_type(). Raw asm code then would use __set_section_core_type() > > directly and C asm() would just __stringify() it. > > > > I figured a bit of bikeshedding would be possible here, so I decided to leave > > this for a later set of patches. But indeed, I agree with you. If we want > > this meshed out now.. let me know and lets bikeshed away... > > It's fine, I don't mind too much. I think asm-generic/asm.h should be > fine for generic asm'isms though. Or assembler.h to match compiler.h. I'd like address this in asm.h but I would hope we can do this as a secondary step, given the length of this patch set already. Thoughts ? > > > > > diff --git a/include/linux/sections.h b/include/linux/sections.h > > > > new file mode 100644 > > > > index 000000000000..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 <mcgrof@kernel.org> > > > > + * > > > > + * 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 <asm/section-core.h> > > > > +#include <linux/export.h> > > > > + > > > > +#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? > > > > We have ELF standard sections, and we have then sections which Linux has introduced > > over the years which are now just known to be expected part of Linux, such as init > > stuff which we free after boot. The combination of the ELF standard sections and > > series of expected sections in Linux across all architectures is what this refers > > to as Linux de-facto/standard/common sections. The header file is intended to > > document these, step by step, and also provide helpers which allow further > > customizations based on these sections. > > Well but your macros are not linker sections. They are "Linux sections", which > appear to give you a start and end symbol name, but does not direct the linker > to create a specific output section. You're right the above can use some love to help explain this better. 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. So for instance, since the following tables are used in C code outside of the code that implemented and manages them: mcgrof@ergon ~/linux-next (git::20160822-linker-table-v5)$ git grep DECLARE_LINKTA| egrep -v "Documentation|tools|tables" arch/x86/kernel/cpu/microcode/core.c:DECLARE_LINKTABLE_RO(struct builtin_fw, builtin_fw); include/linux/dynamic_debug.h:DECLARE_LINKTABLE(struct _ddebug, __verbose); include/linux/jump_label.h:DECLARE_LINKTABLE(struct jump_entry, __jump_table); include/linux/kprobes.h:DECLARE_LINKTABLE(unsigned long, _kprobe_blacklist); Note that the big trick here was to enable users to associate a new custom section in C to a well defined already existing Linux section without modifying the Linux linker script. Then, since as we observe and study uses of how Linux sections are used, we've noticed a pattern -- most declarations of these sections of really of two types, a section ranges or linker table. The patch set then provides generic building blocks for these and ports a few existing custom Linux sections to them as an example. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 24 Aug 2016 22:12:53 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> 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" <mcgrof@kernel.org> wrote: > > > > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > > > > On Fri, 19 Aug 2016 14:34:02 -0700 > > > > mcgrof@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 know... not to be glib, but .section.* would be better and not require > > documentation. > > Well consider the issues below for a second... and keep in mind with linker > tables we are about to open the prospect to add more things into the kernel's > sections more easily than before. > > > CORE does not really add anything as far as I can see. Other types of .text including > > ones which are automatically generated by the compiler, for better or worse, are > > .text.x sections too. > > Actually, sorry, in this case SECTION_ALL() *was* intended for things that are > not linker tables or section ranges, instead this was for globs that want to > use the new section macro names, so we only use this for: > *(SECTION_ALL(SECTION_RODATA)) at this time. It would seem we just did not > have .text.* and friends (other section names documented here). So this is > more of a reaction to provide a way to use a glob for section names if they > have a macro name. > > 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 specific is 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. > > The only one needing SECTION_ALL() it turns out was .rodata: > > - *(.rodata) *(.rodata.*) \ > + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ > > > I would like to see more standardisation of naming convention -- some sections start > > with .., some start with no dots, some use . to separate logical "subsections", others > > use underscores or something else. > > Agreed... Actually while at it -- anyone happen to know why the two dot thing > started creeping up? I'm not sure, but I suspect it may have been due to . not being a valid C symbol name. I'm not saying it's always the wrong thing to do, but I think copy&paste and lack of documentation has left the naming conventions in need of some love. The section names themselves of course can and should have some greppable distinguishing conventions -- we don't need macro name for that. > > I just don't see it would be a problem to simply use the raw names and linker > > wildcards for it. > > A concern here is more abuse over this if we now expose APIs to users to > more easily customize sections. So let's review what the chances are. > > $ git grep DEFINE_SECTION_RANGE| egrep -v "tools|include|Document" > kernel/kprobes.c:DEFINE_SECTION_RANGE(kprobes, SECTION_TEXT); > > These require the actual desired section specified. Do we want > to just hide that ? Or are we OK in assuming users willing to use > proper names here? For me, DEFINE_SECTION_RANGE(kprobes, .text) would be fine. > > BTW, I'm not trying to bikeshed :) This doesn't affect the value of your > > patch at all, it was just an offhand thing I saw. > > Just saying, if you say its ugly please help me with a different name then. Sure, but point taken it's more productive to discuss fundamentals first. Let's consider exact details afterward. > > It's fine, I don't mind too much. I think asm-generic/asm.h should be > > fine for generic asm'isms though. Or assembler.h to match compiler.h. > > I'd like address this in asm.h but I would hope we can do this as a secondary > step, given the length of this patch set already. Thoughts ? It's not a big deal, so whatever suits you. Some of the bugfixes and cleanups could be pushed through various arch and other maintainers first too, which would make the core series look more managable and touch fewer parts. > > Well but your macros are not linker sections. They are "Linux sections", which > > appear to give you a start and end symbol name, but does not direct the linker > > to create a specific output section. > > You're right the above can use some love to help explain this better. > > 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. 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? Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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" <mcgrof@kernel.org> 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 specific is 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 25 Aug 2016 08:05:40 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> 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" <mcgrof@kernel.org> 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 specific is 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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" <mcgrof@kernel.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 25 Aug 2016 19:52:39 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> 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" <mcgrof@kernel.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 25 Aug 2016 23:38:44 -0700 "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > On Aug 25, 2016 8:00 PM, "Nicholas Piggin" <npiggin@gmail.com> wrote: > > > > On Thu, 25 Aug 2016 19:52:39 +0200 > > "Luis R. Rodriguez" <mcgrof@kernel.org> 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" <mcgrof@kernel.org> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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" <mcgrof@kernel.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 26 Aug 2016 15:22:19 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> 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" <mcgrof@kernel.org> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/index.rst b/Documentation/index.rst index a15f81855b39..10c9b867e326 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -14,6 +14,7 @@ Contents: kernel-documentation media/index gpu/index + sections/index Indices and tables ================== diff --git a/Documentation/sections/conf.py b/Documentation/sections/conf.py new file mode 100644 index 000000000000..faa1c57595e1 --- /dev/null +++ b/Documentation/sections/conf.py @@ -0,0 +1,4 @@ +# -*- coding: utf-8; mode: python -*- + +project = 'Linux Kernel ELF sections' +html_search_language = 'en' diff --git a/Documentation/sections/index.rst b/Documentation/sections/index.rst new file mode 100644 index 000000000000..d411e9b22eb3 --- /dev/null +++ b/Documentation/sections/index.rst @@ -0,0 +1,11 @@ +========================= +Linux Kernel ELF sections +========================= + +This book documents the Linux kernel's use of ELF sections, as well as helpers +used throughout the kernel to help declare and define them. + +.. toctree:: + :maxdepth: 4 + + section-core diff --git a/Documentation/sections/section-core.rst b/Documentation/sections/section-core.rst new file mode 100644 index 000000000000..ecf4228bc4f8 --- /dev/null +++ b/Documentation/sections/section-core.rst @@ -0,0 +1,153 @@ +============================== +Core Linux kernel ELF sections +============================== + +About +===== + +This book documents the different standard and custom ELF sections used +on the Linux kernel, which we refer to as the ``core Linux sections``. We +start off by documenting the standard ELF sections used by Linux and move +on to the basic custom ELF sections, followed by a set of helpers. Each +section documented describes the goal of the section, and addresses +concurrency considerations when applicable. + +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Custom linker script + +Standard ELF section use in Linux +================================= + +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Standard ELF section use in Linux + +SECTION_RODATA +-------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_RODATA + +SECTION_RODATA +-------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_TEXT + +SECTION_DATA +------------ +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_DATA + +Linux .init\* sections +====================== + +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Linux init sections + +SECTION_INIT_DATA +----------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_INIT_DATA + +SECTION_INIT_RODATA +------------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_INIT_RODATA + +SECTION_INIT_CALL +----------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_INIT_CALL + +Linux .exit\* sections +====================== + +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Linux exit sections + +SECTION_EXIT +------------ +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_EXIT + +SECTION_EXIT_DATA +----------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_EXIT_DATA + +SECTION_EXIT_CALL +----------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_EXIT_CALL + +Linux .ref\* sections +===================== + +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Linux references to init sections + +SECTION_REF +----------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_REF + +SECTION_REF_DATA +---------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_REF_DATA + +SECTION_REF_RODATA +------------------ +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_REF_RODATA + +Linux section ordering +====================== +.. kernel-doc:: include/asm-generic/section-core.h + :doc: Linux section ordering + +SECTION_ORDER_ANY +----------------- +.. kernel-doc:: include/asm-generic/section-core.h + :doc: SECTION_ORDER_ANY + +Generic Linux kernel section helpers +==================================== + +Introduction +------------- +.. kernel-doc:: include/linux/sections.h + :doc: Introduction + +LINUX_SECTION_ALIGNMENT +----------------------- +.. kernel-doc:: include/linux/sections.h + :functions: LINUX_SECTION_ALIGNMENT + +LINUX_SECTION_SIZE +------------------ +.. kernel-doc:: include/linux/sections.h + :functions: LINUX_SECTION_SIZE + +LINUX_SECTION_EMPTY +------------------- +.. kernel-doc:: include/linux/sections.h + :functions: LINUX_SECTION_EMPTY + +LINUX_SECTION_START +------------------- +.. kernel-doc:: include/linux/sections.h + :functions: LINUX_SECTION_START + +LINUX_SECTION_END +----------------- +.. kernel-doc:: include/linux/sections.h + :functions: LINUX_SECTION_END + +DECLARE_LINUX_SECTION +--------------------- +.. kernel-doc:: include/linux/sections.h + :functions: DECLARE_LINUX_SECTION + +DECLARE_LINUX_SECTION_RO +------------------------ +.. kernel-doc:: include/linux/sections.h + :functions: DECLARE_LINUX_SECTION_RO diff --git a/MAINTAINERS b/MAINTAINERS index 5aec01883020..689c12075842 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5217,6 +5217,20 @@ S: Supported F: drivers/base/power/domain*.c F: include/linux/pm_domain.h +GENERIC SECTIONS +M: "Luis R. Rodriguez" <mcgrof@kernel.org> +M: Josh Poimboeuf <jpoimboe@redhat.com> +M: "H. Peter Anvin" <hpa@zytor.com> +L: linux-arch@vger.kernel.org +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git for-arnd +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git for-arnd +S: Supported +F: include/asm-generic/section-core.h +F: include/asm-generic/sections.h +F: include/asm-generic/vmlinux.lds.h +F: Documentation/sections/section-core.rst + GENERIC UIO DRIVER FOR PCI DEVICES M: "Michael S. Tsirkin" <mst@redhat.com> L: kvm@vger.kernel.org diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index bf8475ce85ee..5422827f1585 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -10,3 +10,4 @@ generic-y += mm-arch-hooks.h generic-y += preempt.h generic-y += sections.h generic-y += trace_clock.h +generic-y += section-core.h diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index 0b10ef2a4372..9a0929576de1 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -50,3 +50,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 0745538b26d3..47923635be16 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -39,3 +39,4 @@ generic-y += termios.h generic-y += timex.h generic-y += trace_clock.h generic-y += unaligned.h +generic-y += section-core.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index f43d2c44c765..42d00806e4fb 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -52,3 +52,4 @@ generic-y += unaligned.h generic-y += user.h generic-y += vga.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 241b9b9729d8..f2c3b656a0e7 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -22,3 +22,4 @@ generic-y += trace_clock.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index 91d49c0a3118..7de674411bed 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -48,3 +48,4 @@ generic-y += unaligned.h generic-y += user.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index 64465e7e2245..38127ce747be 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -62,3 +62,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 1778805f6380..385cd88a9d9e 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -45,3 +45,4 @@ generic-y += types.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild index 1fa084cf1a43..46d7c599d9b8 100644 --- a/arch/frv/include/asm/Kbuild +++ b/arch/frv/include/asm/Kbuild @@ -8,3 +8,4 @@ generic-y += mm-arch-hooks.h generic-y += preempt.h generic-y += trace_clock.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild index 373cb23301e3..1ec04ec1c82b 100644 --- a/arch/h8300/include/asm/Kbuild +++ b/arch/h8300/include/asm/Kbuild @@ -75,3 +75,4 @@ generic-y += unaligned.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/hexagon/include/asm/Kbuild b/arch/hexagon/include/asm/Kbuild index db8ddabc6bd2..37d7bfae7619 100644 --- a/arch/hexagon/include/asm/Kbuild +++ b/arch/hexagon/include/asm/Kbuild @@ -60,3 +60,4 @@ generic-y += unaligned.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/ia64/include/asm/Kbuild b/arch/ia64/include/asm/Kbuild index 502a91d8dbbd..672c6d5da18c 100644 --- a/arch/ia64/include/asm/Kbuild +++ b/arch/ia64/include/asm/Kbuild @@ -9,3 +9,4 @@ generic-y += preempt.h generic-y += trace_clock.h generic-y += vtime.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/m32r/include/asm/Kbuild b/arch/m32r/include/asm/Kbuild index 860e440611c9..6111e1523750 100644 --- a/arch/m32r/include/asm/Kbuild +++ b/arch/m32r/include/asm/Kbuild @@ -11,3 +11,4 @@ generic-y += preempt.h generic-y += sections.h generic-y += trace_clock.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild index eb85bd9c6180..eef72c464c9b 100644 --- a/arch/m68k/include/asm/Kbuild +++ b/arch/m68k/include/asm/Kbuild @@ -35,3 +35,4 @@ generic-y += trace_clock.h generic-y += types.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/metag/include/asm/Kbuild b/arch/metag/include/asm/Kbuild index 29acb89daaaa..50ebd5a30d16 100644 --- a/arch/metag/include/asm/Kbuild +++ b/arch/metag/include/asm/Kbuild @@ -56,3 +56,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/microblaze/include/asm/Kbuild b/arch/microblaze/include/asm/Kbuild index b0ae88c9fed9..c6c2cf6edc98 100644 --- a/arch/microblaze/include/asm/Kbuild +++ b/arch/microblaze/include/asm/Kbuild @@ -11,3 +11,4 @@ generic-y += preempt.h generic-y += syscalls.h generic-y += trace_clock.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/mips/include/asm/Kbuild b/arch/mips/include/asm/Kbuild index 9740066cc631..12f7c5984c03 100644 --- a/arch/mips/include/asm/Kbuild +++ b/arch/mips/include/asm/Kbuild @@ -20,3 +20,4 @@ generic-y += trace_clock.h generic-y += user.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/mn10300/include/asm/Kbuild b/arch/mn10300/include/asm/Kbuild index 1c8dd0f5cd5d..f8145bc85835 100644 --- a/arch/mn10300/include/asm/Kbuild +++ b/arch/mn10300/include/asm/Kbuild @@ -10,3 +10,4 @@ generic-y += preempt.h generic-y += sections.h generic-y += trace_clock.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/nios2/include/asm/Kbuild b/arch/nios2/include/asm/Kbuild index d63330e88379..c9c7cb82b00f 100644 --- a/arch/nios2/include/asm/Kbuild +++ b/arch/nios2/include/asm/Kbuild @@ -63,3 +63,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild index 2832f031fb11..86175e701869 100644 --- a/arch/openrisc/include/asm/Kbuild +++ b/arch/openrisc/include/asm/Kbuild @@ -71,3 +71,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/parisc/include/asm/Kbuild b/arch/parisc/include/asm/Kbuild index f9b3a81aefcd..6f43f33f0e0f 100644 --- a/arch/parisc/include/asm/Kbuild +++ b/arch/parisc/include/asm/Kbuild @@ -29,3 +29,4 @@ generic-y += user.h generic-y += vga.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild index ab9f4e0ed4cf..b49fab7bab2f 100644 --- a/arch/powerpc/include/asm/Kbuild +++ b/arch/powerpc/include/asm/Kbuild @@ -7,3 +7,4 @@ generic-y += mcs_spinlock.h generic-y += preempt.h generic-y += rwsem.h generic-y += vtime.h +generic-y += section-core.h diff --git a/arch/s390/include/asm/Kbuild b/arch/s390/include/asm/Kbuild index 20f196b82a6e..89e74b59f32d 100644 --- a/arch/s390/include/asm/Kbuild +++ b/arch/s390/include/asm/Kbuild @@ -8,3 +8,4 @@ generic-y += mm-arch-hooks.h generic-y += preempt.h generic-y += trace_clock.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/score/include/asm/Kbuild b/arch/score/include/asm/Kbuild index a05218ff3fe4..f089a264cd38 100644 --- a/arch/score/include/asm/Kbuild +++ b/arch/score/include/asm/Kbuild @@ -14,3 +14,4 @@ generic-y += trace_clock.h generic-y += xor.h generic-y += serial.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/sh/include/asm/Kbuild b/arch/sh/include/asm/Kbuild index 751c3373a92c..7b0356dca562 100644 --- a/arch/sh/include/asm/Kbuild +++ b/arch/sh/include/asm/Kbuild @@ -39,3 +39,4 @@ generic-y += termios.h generic-y += trace_clock.h generic-y += ucontext.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/sparc/include/asm/Kbuild b/arch/sparc/include/asm/Kbuild index cfc918067f80..d51b84d6b4b7 100644 --- a/arch/sparc/include/asm/Kbuild +++ b/arch/sparc/include/asm/Kbuild @@ -22,3 +22,4 @@ generic-y += serial.h generic-y += trace_clock.h generic-y += types.h generic-y += word-at-a-time.h +generic-y += section-core.h diff --git a/arch/tile/include/asm/Kbuild b/arch/tile/include/asm/Kbuild index ba35c41c71ff..7b8a652e43ae 100644 --- a/arch/tile/include/asm/Kbuild +++ b/arch/tile/include/asm/Kbuild @@ -41,3 +41,4 @@ generic-y += termios.h generic-y += trace_clock.h generic-y += types.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index 904f3ebf4220..e9849834d55e 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -27,3 +27,4 @@ generic-y += topology.h generic-y += trace_clock.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/arch/unicore32/include/asm/section-core.h b/arch/unicore32/include/asm/section-core.h new file mode 100644 index 000000000000..ebffeed8835d --- /dev/null +++ b/arch/unicore32/include/asm/section-core.h @@ -0,0 +1,19 @@ +#ifndef __UNICORE_SECTION_CORE_ASM_H__ +#define __UNICORE_SECTION_CORE_ASM_H__ +/* + * Copyright (C) 2016 Luis R. Rodriguez <mcgrof@kernel.org> + * + * 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/. + */ + +/* Unicore32 has known to not work properly with the type set, so ignore it */ + +#define __set_section_core_type(___section, ___core, ___name, \ + ___level, ___flags, ___type) \ + .section ___section.___core.___name.___level, ___flags + +#include <asm-generic/section-core.h> + +#endif /* __UNICORE_SECTION_CORE_ASM_H__ */ diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild index 2cfed174e3c9..f6914a57bc16 100644 --- a/arch/x86/include/asm/Kbuild +++ b/arch/x86/include/asm/Kbuild @@ -16,3 +16,4 @@ generic-y += dma-contiguous.h generic-y += early_ioremap.h generic-y += mcs_spinlock.h generic-y += mm-arch-hooks.h +generic-y += section-core.h diff --git a/arch/xtensa/include/asm/Kbuild b/arch/xtensa/include/asm/Kbuild index 28cf4c5d65ef..81ca6816bd72 100644 --- a/arch/xtensa/include/asm/Kbuild +++ b/arch/xtensa/include/asm/Kbuild @@ -31,3 +31,4 @@ generic-y += topology.h generic-y += trace_clock.h generic-y += word-at-a-time.h generic-y += xor.h +generic-y += section-core.h diff --git a/include/asm-generic/section-core.h b/include/asm-generic/section-core.h new file mode 100644 index 000000000000..2ab57e2c4117 --- /dev/null +++ b/include/asm-generic/section-core.h @@ -0,0 +1,341 @@ +#ifndef _ASM_GENERIC_SECTION_CORE_H_ +#define _ASM_GENERIC_SECTION_CORE_H_ +/* + * Linux section core definitions + * + * Copyright (C) 2016 Luis R. Rodriguez <mcgrof@kernel.org> + * + * 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/. + */ + +/** + * DOC: Custom linker script + * + * The Linux vmlinux binary uses a custom linker script on each architecture + * which it uses to strategically place standard ELF sections and also adds + * custom specialized ELF sections. Each architecture defines its own custom + * linker defined in arch/$(ARCH)/kernel/vmlinux.lds.S -- these in turn + * include and use definitions in include/asm-generic/vmlinux.lds.h as well + * as some helpers documented in this chaper. + */ + +/** + * 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 + +/** + * 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 + +/** + * DOC: SECTION_DATA + * + * Macro name for read-write data. + */ +#define SECTION_DATA .data + +/** + * DOC: Linux init sections + * + * These sections are used for code and data structures used during boot or + * module initialization. On architectures that support it (x86, x86_64), all + * this code is freed up by the kernel right before the fist userspace init + * process is called when built-in to the kernel, and if modular it is freed + * after module initialization. Since the code is freed so early, in theory + * there should be no races against freeing this code with other CPUs. Init + * section code and data structures should never be exported with + * EXPORT_SYMBOL*() as the code will quickly become unavailable to the kernel + * after bootup. + */ + +/** + * DOC: SECTION_INIT + * + * Macro name used to annotate code (functions) used only during boot or driver + * initialization. + * + */ +#define SECTION_INIT .init.text + +/** + * DOC: SECTION_INIT_DATA + * + * Macro name used to annotate data structures used only during boot or driver + * initialization. + */ +#define SECTION_INIT_DATA .init.data + +/** + * DOC: SECTION_INIT_RODATA + * + * Macro name used to annotate read-only code (functions) used only during boot + * or driver initialization. + */ +#define SECTION_INIT_RODATA .init.rodata + +/** + * DOC: SECTION_INIT_CALL + * + * Special macro name used to annotate subsystem init call. These calls are + * are now grouped by functionality into separate subsections. Ordering inside + * the subsections is determined by link order. + */ +#define SECTION_INIT_CALL .initcall + +/** + * DOC: Linux exit sections + * + * These sections are used to declare a functions and data structures which + * are only required on exit, the function or data structure will be dropped + * if the code declaring this section is not compiled as a module on + * architectures that support this (x86, x86_64). There is no special case + * handling for this code when built-in to the kernel. + */ + +/** + * DOC: SECTION_EXIT + * + * Macro name used to annotate code (functions) used only during module + * unload. + */ +#define SECTION_EXIT .exit.text + +/** + * DOC: SECTION_EXIT_DATA + * + * Macro name used to annotate data structures used only during module + * unload. + */ +#define SECTION_EXIT_DATA .exit.data + +/** + * DOC: SECTION_EXIT_CALL + * + * Special macro name used to annotate an exit exit routine, order + * is important and maintained by link order. + */ +#define SECTION_EXIT_CALL .exitcall.exit + +/** + * DOC: Linux references to init sections + * + * These sections are used to teach modpost to not warn about possible + * misuses of init section code from other sections. If you use this + * your use case should document why you are certain such use of init + * sectioned code is valid. For more details refer to ``include/linux/init.h`` + * ``__ref``, ``__refdata``, and ``__refconst`` documentation. + */ + +/** + * DOC: SECTION_REF + * + * Macro name used to annotate that code (functions) declared with this section + * has been vetteed as valid for its reference or use of other code (functions) + * or data structures which are part of the init sections. + */ +#define SECTION_REF .ref.text + +/** + * DOC: SECTION_REF_DATA + * + * Macro name used to annotate data structures declared with this section have + * been vetteed for its reference or use of other code (functions) or data + * structures part of the init sections. + */ +#define SECTION_REF_DATA .ref.data + +/** + * DOC: SECTION_REF_RODATA + * + * Macro name used to annotate const code (functions) const data structures + * which has been vetteed for its reference or use of other code (functions) + * or data structures part of the init sections. + */ +#define SECTION_REF_RODATA .ref.rodata + +/** + * DOC: Linux section ordering + * + * Linux may use binutils linker-script 'SORT()' on sections to sort Linux + * sections. Linux has used 'SORT()' in ``include/asm-generic/vmlinux.lds.h`` + * for years. + */ + +/** + * DOC: SECTION_ORDER_ANY + * + * Macro name which can be used as helper to annotate custom section + * ordering at link time is not relevant for specific sections. + */ +#define SECTION_ORDER_ANY any + +/* + * These section _ALL() helpers are for use on linker scripts and helpers + */ +#define SECTION_ALL(__section) \ + __section##.* + +#define __SECTION_CORE(__section, __core, __name, __level) \ + __section.__core.__name.__level + +#define SECTION_CORE_ALL(__section, __core) \ + __section##.##__core##.* + +/* Can be used on foo.S for instance */ +#ifndef __set_section_core_type +# define __set_section_core_type(___section, ___core, ___name, \ + ___level, ___flags, ___type) \ + .section ___section.___core.___name.___level, ___flags, ___type +#endif + +#ifndef __set_section_core +# define __set_section_core(___section, ___core, ___name, ___level, ___flags) \ + .section ___section.___core.___name.___level, ___flags +#endif + +#ifndef __push_section_core +# define __push_section_core(__section, __core, __name, __level, __flags) \ + .pushsection __section.__core.__name.__level, __flags +#endif + +#ifdef __KERNEL__ +#include <linux/stringify.h> +#endif + +#if defined(__ASSEMBLER__) || defined(__ASSEMBLY__) + +# ifdef LINKER_SCRIPT + +# ifndef SECTION_CORE +# define SECTION_CORE(__section, __core, __name, __level) \ + __SECTION_CORE(__section,__core,__name,__level) +# endif + +# else + +# ifndef SECTION_CORE +# define SECTION_CORE(__section, __core, __name, __level) \ + push_section_core(__section, __core, __name, __level,) +# endif + +# ifndef push_section_core +# define push_section_core(__section, __core, __name, __level, __flags) \ + __push_section_core(__section, __core, __name, \ + __level, __stringify(__flags)) +# endif + +# ifndef set_section_core +# define set_section_core(__section, __core, __name, \ + __level, __flags) \ + __set_section_core(__section, __core, __name, \ + __level, __stringify(__flags)) +# endif + +# ifndef set_section_core_type +# define set_section_core_type(__section, __core, __name, \ + __level, __flags, __type) \ + __set_section_core_type(__section, __core, __name, __level, \ + __stringify(__flags), __type) +# endif + +# endif /* LINKER_SCRIPT */ +#else /* defined(__ASSEMBLER__) || defined(__ASSEMBLY__) */ + +# ifndef SECTION_CORE +# define SECTION_CORE(__section, __core, __name, __level) \ + __stringify(__SECTION_CORE(__section,__core,__name,__level)) +# endif + +/* + * 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 + +# ifndef set_section_core +# define set_section_core(__section, __core, __name, __level, __flags) \ + __stringify(__set_section_core_type(__section, __core, __name, \ + __level, __stringify(__flags))) \ + ASM_CMD_SEP +# endif + +/* + * Some architectures (arm, and avr32 are two examples on kprobes) seem + * currently explicitly specify the type [0] -- this can be any of the + * optional constants on ELF: + * + * @progbits - section contains data + * @nobits - section does not contain data (i.e., section only occupies space) + * @note - section contains data which is used by things other than the program + * @init_array - section contains an array of pointers to init functions + * @fini_array - section contains an array of pointers to finish functions + * @preinit_array - section contains an array of pointers to pre-init functions + * + * ARM requires % instead of @. + * + * At least as per nasm (x86/x86_64 only), in the absence of qualifiers the + * defaults are as follows: + * + * section .text progbits alloc exec nowrite align=16 + * section .rodata progbits alloc noexec nowrite align=4 + * section .lrodata progbits alloc noexec nowrite align=4 + * section .data progbits alloc noexec write align=4 + * section .ldata progbits alloc noexec write align=4 + * section .bss nobits alloc noexec write align=4 + * section .lbss nobits alloc noexec write align=4 + * section .tdata progbits alloc noexec write align=4 tls + * section .tbss nobits alloc noexec write align=4 tls + * section .comment progbits noalloc noexec nowrite align=1 + * section other progbits alloc noexec nowrite align=1 + * + * gas should have sensible defaults for architectures... + * + * [0] http://www.nasm.us/doc/nasmdoc7.html + */ +# ifndef set_section_core_type +# define set_section_core_type(__section, __core, __name, __level, \ + __flags, __type) \ + __stringify(__set_section_core_type(__section, __core, \ + __name, __level, \ + __stringify(__flags), \ + __type)) \ + ASM_CMD_SEP +# endif + +# ifndef push_section_core +# define push_section_core(__section, __core, __name, \ + __level, __flags) \ + __stringify(__push_section_core(__section, __core, \ + __name, __level, \ + __stringify(__flags))) \ + ASM_CMD_SEP +# endif + +#endif /* defined(__ASSEMBLER__) || defined(__ASSEMBLY__) */ +#endif /* _ASM_GENERIC_SECTION_CORE_H_ */ diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h index af0254c09424..298252df3c81 100644 --- a/include/asm-generic/sections.h +++ b/include/asm-generic/sections.h @@ -1,6 +1,8 @@ #ifndef _ASM_GENERIC_SECTIONS_H_ #define _ASM_GENERIC_SECTIONS_H_ +#include <asm/section-core.h> + /* References to section boundaries */ #include <linux/compiler.h> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 24563970ff7b..731087276a32 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -55,6 +55,7 @@ #endif #include <linux/export.h> +#include <asm/section-core.h> /* Align . to a 8 byte boundary equals to maximum function alignment. */ #define ALIGN_FUNCTION() . = ALIGN(8) @@ -198,8 +199,8 @@ /* .data section */ #define DATA_DATA \ - *(.data) \ - *(.ref.data) \ + *(SECTION_DATA) \ + *(SECTION_REF_DATA) \ *(.data..shared_aligned) /* percpu related */ \ MEM_KEEP(init.data) \ MEM_KEEP(exit.data) \ @@ -262,9 +263,9 @@ */ #define RO_DATA_SECTION(align) \ . = ALIGN((align)); \ - .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ + SECTION_RODATA : AT(ADDR(SECTION_RODATA) - LOAD_OFFSET) { \ VMLINUX_SYMBOL(__start_rodata) = .; \ - *(.rodata) *(.rodata.*) \ + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ RO_AFTER_INIT_DATA /* Read only after init */ \ *(__vermagic) /* Kernel version magic */ \ . = ALIGN(8); \ @@ -394,7 +395,7 @@ \ /* __*init sections */ \ __init_rodata : AT(ADDR(__init_rodata) - LOAD_OFFSET) { \ - *(.ref.rodata) \ + *(SECTION_REF_RODATA) \ MEM_KEEP(init.rodata) \ MEM_KEEP(exit.rodata) \ } \ @@ -432,8 +433,8 @@ * during second ld run in second ld pass when generating System.map */ #define TEXT_TEXT \ ALIGN_FUNCTION(); \ - *(.text.hot .text .text.fixup .text.unlikely) \ - *(.ref.text) \ + *(.text.hot SECTION_TEXT .text.fixup .text.unlikely) \ + *(SECTION_REF) \ MEM_KEEP(init.text) \ MEM_KEEP(exit.text) \ @@ -527,11 +528,11 @@ /* init and exit section handling */ #define INIT_DATA \ - *(.init.data) \ + *(SECTION_INIT_DATA) \ MEM_DISCARD(init.data) \ KERNEL_CTORS() \ MCOUNT_REC() \ - *(.init.rodata) \ + *(SECTION_INIT_RODATA) \ FTRACE_EVENTS() \ TRACE_SYSCALLS() \ KPROBE_BLACKLIST() \ @@ -549,24 +550,24 @@ EARLYCON_TABLE() #define INIT_TEXT \ - *(.init.text) \ + *(SECTION_INIT) \ *(.text.startup) \ MEM_DISCARD(init.text) #define EXIT_DATA \ - *(.exit.data) \ + *(SECTION_EXIT_DATA) \ *(.fini_array) \ *(.dtors) \ MEM_DISCARD(exit.data) \ MEM_DISCARD(exit.rodata) #define EXIT_TEXT \ - *(.exit.text) \ + *(SECTION_EXIT) \ *(.text.exit) \ MEM_DISCARD(exit.text) #define EXIT_CALL \ - *(.exitcall.exit) + *(SECTION_EXIT_CALL) /* * bss (Block Started by Symbol) - uninitialized data diff --git a/include/linux/sections.h b/include/linux/sections.h new file mode 100644 index 000000000000..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 <mcgrof@kernel.org> + * + * 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 <asm/section-core.h> +#include <linux/export.h> + +#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. + */ + +/** + * LINUX_SECTION_ALIGNMENT - get section alignment + * + * @name: section name + * + * Gives you the alignment for the section. + */ +#define LINUX_SECTION_ALIGNMENT(name) __alignof__(*VMLINUX_SYMBOL(name)) + +/** + * LINUX_SECTION_SIZE - get number of entries in the section + * + * @name: section name + * + * This gives you the number of entries in the section. + * Example usage: + * + * unsigned int num_frobs = LINUX_SECTION_SIZE(frobnicator_fns); + */ +#define LINUX_SECTION_SIZE(name) \ + ((VMLINUX_SYMBOL(name##__end)) - (VMLINUX_SYMBOL(name))) + +/** + * LINUX_SECTION_EMPTY - check if section has no entries + * + * @name: section name + * + * Returns true if section is emtpy. + * + * bool is_empty = LINUX_SECTION_EMPTY(frobnicator_fns); + */ +#define LINUX_SECTION_EMPTY(name) (LINUX_SECTION_SIZE(name) == 0) + +/** + * LINUX_SECTION_START - get address of start of section + * + * @name: section name + * + * This gives you the start address of the section. + * This should give you the address of the first entry. + * + */ +#define LINUX_SECTION_START(name) VMLINUX_SYMBOL(name) + +/** + * LINUX_SECTION_END - get address of end of the section + * + * @name: section name + * + * This gives you the end address of the section. + * This should give you the address of the end of the + * section. This will match the start address if the + * section is empty. + */ +#define LINUX_SECTION_END(name) VMLINUX_SYMBOL(name##__end) + +/** + * DECLARE_LINUX_SECTION - Declares a custom Linux section + * + * @type: type of custom Linux section + * @name: custom section name + * + * Declares a read-write custom Linux section + */ +#define DECLARE_LINUX_SECTION(type, name) \ + extern type VMLINUX_SYMBOL(name)[], \ + VMLINUX_SYMBOL(name##__end)[] + +/** + * DECLARE_LINUX_SECTION_RO - Declares a read-only custom Linux section + * + * @type: type of custom Linux section + * @name: custom section name + * + * Declares a read-only custom Linux section + */ +#define DECLARE_LINUX_SECTION_RO(type, name) \ + extern const type VMLINUX_SYMBOL(name)[], \ + VMLINUX_SYMBOL(name##__end)[] + +#define __SECTION_TYPE(section, type, name, level) \ + #section "." #type "." #name "." #level + +#endif /* __ASSEMBLY__ */ + +#endif /* _LINUX_SECTIONS_H */