All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@infradead.org>
Subject: Re: [PATCH] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode
Date: Sun, 27 Apr 2014 20:48:17 +0200	[thread overview]
Message-ID: <9583205.X1uy75Zhv6@avalon> (raw)
In-Reply-To: <Pine.LNX.4.64.1404261627390.21367@axis700.grange>

Hi Guennadi,

On Saturday 26 April 2014 17:28:24 Guennadi Liakhovetski wrote:
> On Fri, 28 Mar 2014, Laurent Pinchart wrote:
> > On Friday 28 March 2014 18:44:04 Guennadi Liakhovetski wrote:
> > > On Fri, 28 Mar 2014, Laurent Pinchart wrote:
> > > > On Thursday 27 March 2014 22:34:07 Guennadi Liakhovetski wrote:
> > > > > It turns out, that 64-bit compilations sometimes align structs
> > > > > within other structs on 32-bit boundaries, but in other cases
> > > > > alignment is done on 64-bit boundaries, adding padding if necessary.
> > > > 
> > > > You make it sound like the behaviour is random, I'm pretty sure it
> > > > isn't
> > > > 
> > > > :-)
> > > 
> > > I didn't mean it was random, I just meant it is not be as simple as
> > > "align always." E.g. if there are only 32-bit fields in the embedded
> > > struct, it won't be aligned, below I explain a bit with pointers. I just
> > > don't know the exact logic, that's used there.
> > 
> > The logic is basically that fields are aligned within structures to a
> > multiple of their native access size, and structures are aligned to a
> > multiple of the access size of the largest field. If a structure on a
> > 64-bit systems contains a pointer the pointer field will be aligned to a
> > multiple of 8 bytes within the structure, and instances of the structure
> > will be aligned to multiples of 8 bytes as well. If that structure is
> > embedded inside another structure, it will be placed on an 8 bytes
> > boundary, possibly creating a gap if the fields before the structure
> > don't add up to a multiple of 8 bytes. This is what happens here.
> 
> Yes, that's what I thought too, but I didn't have a documented
> confirmation at hand, so, I left it a bit vague :) Have you got a pointer
> to this?

AFAIK how data are aligned in memory isn't part of the C standard but is 
defined by the platform ABI. For instance see the ARM Procedure Call Standard 
(AAPCS -  
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf). 
There's probably a similar document for x86.

-- 
Regards,

Laurent Pinchart


      reply	other threads:[~2014-04-27 18:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 21:34 [PATCH] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode Guennadi Liakhovetski
2014-03-28 16:31 ` Laurent Pinchart
2014-03-28 17:44   ` Guennadi Liakhovetski
2014-03-28 18:01     ` Laurent Pinchart
2014-04-26 15:28       ` Guennadi Liakhovetski
2014-04-27 18:48         ` Laurent Pinchart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9583205.X1uy75Zhv6@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.