| Message ID | 1465504244-17175-9-git-send-email-daniel.kiper@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/06/2016 21:30, Daniel Kiper wrote: > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> > --- > doc/multiboot.texi | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi > index c81b2ea..bf02a1b 100644 > --- a/doc/multiboot.texi > +++ b/doc/multiboot.texi > @@ -1384,6 +1384,7 @@ document, but are included for prospective operating system and boot > loader writers. > > @menu > +* C structure alignment and padding consideration:: > * Notes on PC:: > * BIOS device mapping techniques:: > * Example OS code:: > @@ -1391,6 +1392,22 @@ loader writers. > @end menu > > > +@node C structure alignment and padding consideration > +@section C structure alignment and padding consideration > + > +Many C compilers try to optimize memory accesses aligning structure "by aligning" > +members properly. Usually they reach the goal by adding some padding. What does "properly" mean here? The default padding will be specified by the default ABI the compiler conforms to. > +This is very useful thing in general. However, if you try to mix assembler > +with C or use C to implement structure low level access this behavior > +may lead, at least, to quite surprising results. Hence, compiler should > +be instructed to not optimize such accesses. Usually it is done by special > +attribute added to structure definition, e.g. GCC compatible sources use > +@samp{__attribute__ ((__packed__))} for this purpose. However, this is not > +required if it is known that its members are properly aligned and compiler > +does not do any optimization. Very good example of this is shown below in > +@file{multiboot2.h} file. I am not sure what you are trying to say. ~Andrew
On Thu, Jun 09, 2016 at 11:07:12PM +0100, Andrew Cooper wrote: > On 09/06/2016 21:30, Daniel Kiper wrote: > > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> > > --- > > doc/multiboot.texi | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi > > index c81b2ea..bf02a1b 100644 > > --- a/doc/multiboot.texi > > +++ b/doc/multiboot.texi > > @@ -1384,6 +1384,7 @@ document, but are included for prospective operating system and boot > > loader writers. > > > > @menu > > +* C structure alignment and padding consideration:: > > * Notes on PC:: > > * BIOS device mapping techniques:: > > * Example OS code:: > > @@ -1391,6 +1392,22 @@ loader writers. > > @end menu > > > > > > +@node C structure alignment and padding consideration > > +@section C structure alignment and padding consideration > > + > > +Many C compilers try to optimize memory accesses aligning structure > > "by aligning" > > > +members properly. Usually they reach the goal by adding some padding. > > What does "properly" mean here? The default padding will be specified > by the default ABI the compiler conforms to. Right. I do not want to go into the details in this section and duplicate anything which is much better described somewhere else. So, that is why I use "properly" here. However, if you think that it can be phrased better then drop me a line. > > +This is very useful thing in general. However, if you try to mix assembler > > +with C or use C to implement structure low level access this behavior > > +may lead, at least, to quite surprising results. Hence, compiler should > > +be instructed to not optimize such accesses. Usually it is done by special > > +attribute added to structure definition, e.g. GCC compatible sources use > > +@samp{__attribute__ ((__packed__))} for this purpose. However, this is not > > +required if it is known that its members are properly aligned and compiler > > +does not do any optimization. Very good example of this is shown below in > > +@file{multiboot2.h} file. > > I am not sure what you are trying to say. Do you refer to whole paragraph or last sentence? In general I would like to say that guys should pay attention to proper usage of struct construct in C and be aware that bad things may happen when they introduce new tags structs without __packed__ attribute. However, they also should be aware that __packed__ is not always required. And tag structs in multiboot2.h file does not contain __packed__ attribute because they are build in proper way. I hope that helps. Daniel
diff --git a/doc/multiboot.texi b/doc/multiboot.texi index c81b2ea..bf02a1b 100644 --- a/doc/multiboot.texi +++ b/doc/multiboot.texi @@ -1384,6 +1384,7 @@ document, but are included for prospective operating system and boot loader writers. @menu +* C structure alignment and padding consideration:: * Notes on PC:: * BIOS device mapping techniques:: * Example OS code:: @@ -1391,6 +1392,22 @@ loader writers. @end menu +@node C structure alignment and padding consideration +@section C structure alignment and padding consideration + +Many C compilers try to optimize memory accesses aligning structure +members properly. Usually they reach the goal by adding some padding. +This is very useful thing in general. However, if you try to mix assembler +with C or use C to implement structure low level access this behavior +may lead, at least, to quite surprising results. Hence, compiler should +be instructed to not optimize such accesses. Usually it is done by special +attribute added to structure definition, e.g. GCC compatible sources use +@samp{__attribute__ ((__packed__))} for this purpose. However, this is not +required if it is known that its members are properly aligned and compiler +does not do any optimization. Very good example of this is shown below in +@file{multiboot2.h} file. + + @node Notes on PC @section Notes on PC
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> --- doc/multiboot.texi | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)