>>>>> "Olaf" == Olaf Petzold <[EMAIL PROTECTED]> writes:
Olaf> typedef struct { flag_t inuse; flag_t valid; double um[65536] }
Olaf> __attribute__ ((aligned)) shm_slut_t;
>>
Olaf> ??? Is it guarantee that all structures (inside shm, inside
Olaf> local static copy, inside kernel space code produced by Gnu-C
Olaf> and user space program compiled by Gnu-C++) have the same
Olaf> aligment - even if compiled with the Option -align-double?
>> Same alignment as what?
Olaf> The same aligment as it used inside user space and kernel space
Olaf> - the code is produced by different compilers (C/C++)
I guess I missed some part of this... why different compilers?
>>> ... It should be noted that using -malign-double option can lead
>>> to different struct fields aligning, even in the same app.
To me this means "different from the alignment you got without that
switch".
Olaf> If this happens I'm on the wrong site of the sun. My basic
Olaf> question was which option has more priority, the compiler cmd
Olaf> line option -align-double or the directive __attribute__
Olaf> ((aligned)) xx_t, has the structure allways the same size (even
Olaf> producted by different GNU compilers)...
I would assume the directive does *not* override; at least the
documentation suggests that, because it says that ((aligned)) will
*increase* the alignment from the default to match what you ask for.
So if you say --align-double, that (I assume) means you want the
default alignment to be 8. ((aligned (4))) would therefore not have
any effect. Note that the documentation also says that you can use
"packed" to force the default alignment to be 1, so combining
((aligned)) and ((packed)) can bring the alignment down.
>> If you compile the same structure declaration n times with the
>> same compiler alignment controls, for the same platform, it should
>> produce the same alignment. That seems rather obvious; the
>> compiler is broken if that fails.
Olaf> I agree, but see above.
Olaf> [...]
>> So, if you have a struct that contains a char, a uint32, and a
>> struct of two uint16s, in that order. If the minimum alignments
>> are used, the offsets will be 0, 4, and 8, with the inner
>> structure having a total length of 4 and its components are at
>> offsets 8 and 10 from the start of the outer struct. The struct
>> size is 12, which is a multiple of 4.
Olaf> I understood that.
>> It would also be legal for everything to be rounded up to a
>> multiple of 8, making the inner struct size 16 (with alignment 8)
>> and the outer struct having its fields at 0, 8, and 16, for a
>> total size of 32.
Olaf> It's clear as well. Please have a look to the following
Olaf> example:...
Olaf> At first it's seems the compiler option -malign-double overides
Olaf> the attributes, it's important to know.
Interesting, I see --align-double does something different from what I
had guessed, since most structs are unaffected.
Olaf> Secondly why is there a
Olaf> difference between x1_t and x2_t ?? (it's interesting for me)
Beats me! Looks like a bug, unless there's something important hidden
elsewhere in the code.
Olaf> What does the different offsets mean for the programer (like
Olaf> me)? I guess, the compiler has to be responsible that I get by
Olaf> acess on xX.sX_t.ui16[0] allways the same value at all options
Olaf> and attributes.
Um, the compiler has to be responsible for computing the right
offsets, and for a given set of options/attributes the offsets should
be constant, but change the options and the offsets may change.
paul
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
