From: matthieu castet <castet.matthieu@free.fr>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ubi: kill homegrown endian macros
Date: Fri, 18 May 2007 21:55:08 +0200 [thread overview]
Message-ID: <464E049C.9050006@free.fr> (raw)
In-Reply-To: <1179455959.2859.527.camel@shinybook.infradead.org>
David Woodhouse wrote:
> On Thu, 2007-05-17 at 20:30 +0000, Matthieu CASTET wrote:
>> On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
>>
>>> On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> When I tested this on ARM, the output for je32_to_cpu et al was fine.
> For _other_ structures where I'd used __attribute__((packed)) to be
> safe, gcc would emit code to handle unaligned loads. But not in the
> simple case where the struct has only one member.
I don't think it is true.
When porting some summary stuff to bootloader, I hit some unaligned
access problem :
in summary.c:405 there is a
switch (je16_to_cpu(((struct jffs2_sum_unknown_flash *)sp)->nodetype)) {
and
struct jffs2_sum_unknown_flash
{
jint16_t nodetype; /* node type */
};
note that sp isn't aligned to a 32 bits boundary (it can be anything and
depend for example of the size of the dirent name).
if gcc doesn't emit code to handle unaligned loads in this case, there
is unaligned access.
When compiling my code for arm, I use a gcc-4.1.1 with a bug and it
break. With another compiler (last gcc from codesourcery) it worked
(because gcc emit load it bit per bit).
>
> Are you suggesting that this has changed since I did my testing?
>
Which version of gcc did you try ?
Matthieu
next prev parent reply other threads:[~2007-05-18 19:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-17 14:32 [PATCH] ubi: kill homegrown endian macros Christoph Hellwig
2007-05-17 14:50 ` Artem Bityutskiy
2007-05-17 14:56 ` Christoph Hellwig
2007-05-17 15:09 ` Artem Bityutskiy
2007-05-17 17:29 ` Andrew Morton
2007-05-17 17:46 ` Artem Bityutskiy
2007-05-17 18:18 ` Andrew Morton
2007-05-17 20:32 ` Artem Bityutskiy
2007-05-17 20:30 ` Matthieu CASTET
2007-05-18 2:39 ` David Woodhouse
2007-05-18 2:57 ` John Anthony Kazos Jr.
2007-05-18 3:17 ` David Woodhouse
2007-05-18 11:52 ` John Anthony Kazos Jr.
2007-05-18 14:52 ` David Woodhouse
2007-05-18 22:00 ` Segher Boessenkool
2007-05-19 2:07 ` David Woodhouse
2007-05-19 12:24 ` Segher Boessenkool
2007-05-20 11:29 ` David Woodhouse
2007-05-18 19:55 ` matthieu castet [this message]
2007-05-19 1:29 ` David Woodhouse
2007-05-18 20:30 ` matthieu castet
2007-05-17 20:42 ` Al Viro
2007-05-17 20:53 ` Al Viro
2007-05-18 6:58 ` Artem Bityutskiy
2007-05-18 8:38 ` Al Viro
2007-05-17 21:14 ` Dmitry Torokhov
2007-05-17 21:29 ` Al Viro
2007-05-17 21:33 ` David Miller
2007-05-17 21:47 ` Al Viro
2007-05-17 21:26 ` Al Viro
2007-05-17 20:56 ` David Miller
2007-05-17 21:03 ` Al Viro
2007-05-17 15:50 ` David Woodhouse
2007-05-17 18:12 ` Christoph Hellwig
2007-05-17 18:23 ` Sam Ravnborg
2007-05-17 18:36 ` Christoph Hellwig
2007-05-17 20:18 ` Jeremy Fitzhardinge
2007-05-17 20:27 ` Matthieu CASTET
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=464E049C.9050006@free.fr \
--to=castet.matthieu@free.fr \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.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.