Re: [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section

2016-06-10 Thread Daniel Kiper 
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 
> > ---
> >  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

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images

2016-06-10 Thread Daniel Kiper 
On Thu, Jun 09, 2016 at 10:36:29PM +0100, Andrew Cooper wrote:
> On 09/06/2016 21:30, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper 
> > ---
> >  doc/multiboot.texi |   56 
> > 
> >  doc/multiboot2.h   |   24 ++
> >  2 files changed, 80 insertions(+)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index 130176a..f1e0e09 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -359,6 +359,7 @@ executable header.
> >  * Console header tags::
> >  * Module alignment tag::
> >  * EFI boot services tag::
> > +* Relocatable header tag::
> >
> >  @end menu
> >
> > @@ -681,6 +682,47 @@ u32 | size = 8  |
> >  This tag indicates that payload supports starting without
> >  terminating boot services.
> >
> > +@node Relocatable header tag
> > +@subsection Relocatable header tag
> > +
> > +@example
> > +@group
> > ++---+
> > +u16 | type = 10 |
> > +u16 | flags |
> > +u32 | size = 24 |
> > +u32 | min_addr  |
> > +u32 | max_addr  |
> > +u32 | align |
> > +u32 | preference|
> > ++---+
> > +@end group
> > +@end example
> > +
> > +This tag indicates that image is relocatable.
> > +
> > +The meaning of each field is as follows:
> > +
> > +@table @code
> > +@item min_addr
> > +Lowest possible physical address at which image should be loaded.
> > +Boot loader cannot load any part of image below this address.
>
> "The bootloader".

This and earlier comments show, what I know very well, that a/the
English stuff is huge pain for me. Ehh... It looks that I should
not update any docs... ;-))) Anyway, thank you for your comments!

[...]

> > +struct multiboot_header_tag_relocatable
> > +{
> > +  multiboot_uint16_t type;
> > +  multiboot_uint16_t flags;
> > +  multiboot_uint32_t size;
> > +  multiboot_uint32_t min_addr;
> > +  multiboot_uint32_t max_addr;
>
> 64bit multiboot2 payloads could reasonably expect to be able to have
> themselves relocated about the 4G boundary.

That is true but in general the multiboot2 protocol is 32-bit stuff.
So, I prefer to stay in 32-bit domain. Just in case. If we need to use
full blown 64-bit thing then, IMO, we should introduce new protocol
(e.g. multiboot3) with full 64-bit support, probably compatible with
32-bit stuff to some extent.

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel