[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment a
From: |
Daniel Kiper |
Subject: |
Re: [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section |
Date: |
Fri, 10 Jun 2016 19:58:08 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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 <address@hidden>
> > ---
> > 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
> >
> >
> > address@hidden C structure alignment and padding consideration
> > address@hidden 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
> > address@hidden ((__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
> > address@hidden 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
- [MULTIBOOT2 DOC PATCH 03/10] multiboot2: Fix description of EFI boot services tag, (continued)
- [MULTIBOOT2 DOC PATCH 03/10] multiboot2: Fix description of EFI boot services tag, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 05/10] multiboot2: Add description of EFI image handle tags, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 09/10] multiboot2: Add me to authors, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 07/10] multiboot2: Say that memory maps may not be available on EFI platforms, Daniel Kiper, 2016/06/09
- [MULTIBOOT2 DOC PATCH 10/10] multiboot2: Bump version to 2.0, Daniel Kiper, 2016/06/09