From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vipin Kumar <vipin.kumar@st.com>
Date: Tue, 5 Oct 2010 09:15:36 +0530
Subject: [U-Boot] packed attribute problem
In-Reply-To: <4CA9CC04.5020800@emk-elektronik.de>
References: <4CA9A095.9000900@st.com>
	<20101004101714.A19931539A0@gemini.denx.de>
	<4CA9ACAA.2020001@st.com>
	<20101004104443.09AE41539A0@gemini.denx.de>
	<4CA9B2DA.6030407@emk-elektronik.de> <4CA9B3EF.7000704@st.com>
	<4CA9BE94.6000401@emk-elektronik.de>
	<20101004122900.A090B1539A0@gemini.denx.de>
	<4CA9CC04.5020800@emk-elektronik.de>
Message-ID: <4CAA9F60.9000007@st.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 10/4/2010 6:13 PM, Reinhard Meyer wrote:
>> > bar:
>> >         @ Function supports interworking.
>> >         @ args = 0, pretend = 0, frame = 0
>> >         @ frame_needed = 0, uses_anonymous_args = 0
>> >         @ link register save eliminated.
>> >         @ lr needed for prologue
>> >         mov     r2, #5
>> >         mov     r3, #4096
>> >         str     r2, [r3, #0]
>> >         bx      lr
>> >         .size   bar, .-bar
>> >         .ident  "GCC: (GNU) 4.2.2"
>> > 
>> > 
>> > Note that this is with GCC 4.2.2. Even GCC 4.0.0 behaves the same, so
>> > this is *not* an issue with very recent tool chains.
> OK, for directly adressing elements inside a packed struct;
> but the original post said:
> 
> "struct xyz {
> 	int	x;
> 	int	y;
> 	int	z[CONST];
> } __attribute__ ((packed));
> 
> struct xyz *abc;
> u32 * status_reg = (u32 *)&abc->z[0];
> 
> writel(status, status_reg);"
> 
> So the "status_reg" pointer is in a completely unrelated (to the packed struct)
> "u32 *" and still the access is done like it was packed. If the
> compiler silently drags that attribute along into the "u32 *"
> THAT is really sick!
> 

Yes, This is exactly what I wanted to point out. I can see this behavior with 
gcc-4.5.0 but the same code works well with gcc-4.2.4

Vipin