Dear all,
I wanted to point out clues about why GCC manages the packed attribute
in this way.
The behavior is suspiciously similar to what the ARM RVDS compiler
(armcc) does with the __packed qualifier:
[...]
Thus if you wish to define a pointer to a word that can be at any address
(i.e.
Hi Scott,
On Tue, 5 Oct 2010 13:43:01 +0200
Detlev Zundel d...@denx.de wrote:
Hi Reinhard,
[...]
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;
On Thu, 7 Oct 2010 11:59:07 +0200
Detlev Zundel d...@denx.de wrote:
Hi Scott,
So instead of the code breaking in the obvious situation where the
unaligned address is assigned to a pointer type that implies alignment,
it breaks when sufficient barriers to optimization are added that the
Dear Scott Wood,
In message 20101007114634.70e0f...@udp111988uds.am.freescale.net you wrote:
I think this gets down to how such pointers are generated -- if you
stick with well-defined C, the compiler/ABI should be able to avoid
generating an unaligned pointer.
It is a pretty common method
On Thu, 7 Oct 2010 19:57:01 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Scott Wood,
In message 20101007114634.70e0f...@udp111988uds.am.freescale.net you wrote:
I think this gets down to how such pointers are generated -- if you
stick with well-defined C, the compiler/ABI should be able
Dear Scott Wood,
In message 20101007135257.05a93...@udp111988uds.am.freescale.net you wrote:
It is a pretty common method to use a pointer to some struct (for
example, some form of PDU) and make it point to some I/O buffer.
Yes, but at that point we are not talking about well-defined C,
On Thu, 7 Oct 2010 21:31:43 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Scott Wood,
In message 20101007135257.05a93...@udp111988uds.am.freescale.net you wrote:
It is a pretty common method to use a pointer to some struct (for
example, some form of PDU) and make it point to some I/O
Hi Reinhard,
[...]
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
On Tue, 5 Oct 2010 13:43:01 +0200
Detlev Zundel d...@denx.de wrote:
Hi Reinhard,
[...]
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
On 10/4/2010 4:14 PM, Wolfgang Denk wrote:
Dear Vipin Kumar,
In message 4ca9acaa.2020...@st.com you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM
Dear Vipin Kumar,
In message 4ca9a095.9000...@st.com you wrote:
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)abc-z[0];
writel(status,
Dear Reinhard Meyer,
In message 4ca9be94.6000...@emk-elektronik.de you wrote:
Do you imply that the code is really different when the pointer gets
its value by assigning it NOT to a packed entity? Hard to believe.
This is a special feature of GCC on ARM.
- cat foo.c
#define writel(v,a)
Dear Vipin Kumar,
In message 4ca9b316.3050...@st.com you wrote:
Hm... Why do these structs have any __attribute__ ((packed)) at all?
Even I could not understand that very well
Eventually alignment of these structs cannot be guaranteed?
In my opinion it can be guaranteed.
btw, I
Dear Wolfgang Denk and Reinhard Meyer,
The compiler (4.4.1) generates the expected 32bit store instruction when using:
struct p {
int n;
} __attribute__ ((packed, aligned(4)));
In case of hardware registers, I have yet to see a case where this is not true.
Regards,
Francesco
On Mon,
Dear Vipin Kumar,
A writel to status_reg results in byte by byte writing
How do you know that? Disassembly? Bus snooping?
Disassembly
I agree with you. I always considered such behaviour of the ARM C
compiler a bug, and still do. However, people with better knowledge
of the ARm
Dear Reinhard Meyer,
In message 4ca9cc04.5020...@emk-elektronik.de you wrote:
In a non-packed struct an int will never be unaligned
(unless you use an unaligned pointer to the whole struct)
Which may happen for example when overlaying such a struct on top of
some I/O buffer.
In a packed
On 10/4/2010 3:47 PM, Wolfgang Denk wrote:
Dear Vipin Kumar,
Dear Wolfgang
In message 4ca9a095.9000...@st.com you wrote:
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 *
Dear Balau,
In message aanlktik6fcn-n+4ig0vv67t7rvsatb16=27qya8d6...@mail.gmail.com you
wrote:
The compiler (4.4.1) generates the expected 32bit store instruction when
using:
struct p {
int n;
} __attribute__ ((packed, aligned(4)));
Confirmed. Thanks for pointing this out.
Dear Vipin Kumar,
In message 4ca9acaa.2020...@st.com you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM system?
Yes, it is on an ARM system
On 10/4/2010 4:26 PM, Reinhard Meyer wrote:
Dear Wolfgang Denk, Vipin Kumar,
In message 4ca9acaa.2020...@st.com you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is
Dear Wolfgang Denk, Vipin Kumar,
In message 4ca9acaa.2020...@st.com you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM system?
Yes, it is on an ARM
Hi All,
I encountered a problem something like
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);
This writel results in writing byte by byte on the address
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
23 matches
Mail list logo
