Alignment issue on x86_64?

Rémi Cardona remi@gentoo.org
Mon Jun 23 16:26:00 GMT 2008


John Fine a écrit :
> I don't think that is an alignment issue.  What you wrote isn't even 
> convincing that there is anything wrong with the way type was passed.  
> But I don't know what exactly an Atom is, so I'm not sure how it should 
> be passed.  Most importantly, how many bits are there in an Atom as 
> compiled for your architecture.

An Atom is a standard X11 object ID. There's a first typedef from Atom 
to CARD32, and depending on the architecture, CARD32 is defined like so:

#ifdef LONG64
typedef unsigned long CARD64;
typedef unsigned int CARD32;
#else
typedef unsigned long CARD32;
#endif
#if !defined(WORD64) && !defined(LONG64)
typedef unsigned long long CARD64;
#endif

(this is taken from <X11/Xmd.h>)

So I believe on x86_64, that would end up being "unsigned int".

> 1) It is correct to pass an Atom as 32 bits with the high 32 undefined, 
> and the called routine correctly uses it that way and you are confused 
> by gdb and your problem is somewhere else.
> 
> 2) It is correct to pass an Atom as 32 bits with the high 32 undefined, 
> but the called routine incorrectly uses the high bits.
> 
> 3) It is incorrect to pass an Atom as 32 bits with the high 32 undefined.

Atom being such a "simple" integer type, I'm not really sure what to do 
here.

Thanks for your help

-- 
Rémi Cardona
LRI, INRIA
remi.cardona@lri.fr
remi@gentoo.org



More information about the Gcc-help mailing list