[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110119221538.GB23544@Krystal>
Date: Wed, 19 Jan 2011 17:15:38 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: David Miller <davem@...emloft.net>
Cc: rostedt@...dmis.org, richm@...elvet.org.uk, 609371@...s.debian.org,
ben@...adent.org.uk, sparclinux@...r.kernel.org,
linux-kernel@...r.kernel.org, fweisbec@...il.com, mingo@...hat.com
Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:
Unknown relocation: 36
* David Miller (davem@...emloft.net) wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Date: Wed, 19 Jan 2011 13:20:53 -0500
>
> > Now what I'm discussing with David Miller is if creating a
> >
> > __long_packed_aligned
> >
> > and using it for *both* type and variable alignment would be more palatable (it
> > also works, and is more compact).
>
> As I mentioned in another reply, we should not be using packed.
>
> Packed has other implications, which makes it use byte-at-a-time accesses
> for all parts of a structure when you tag it with 'packed'. GCC doesn't
> try to be clever and see that actually such accesses are safe.
Please see my explanation about the difference between "packed" and "packed,
aligned(4 or 8)" in the other thread. I share your concern about ugly code
generated by "packed", but my tests with a sparc32 gcc show that using both
packed and aligned attributes generate nice code.
> If plain "__long_aligned" works and, since you're tagging it to the structure
> definition, it only specifies a minimum-alignment, then I'm fine with using
> that to fix this.
I'd prefer to add the "packed" to ensure that gcc never decides for some odd
reason to use an alignment larger than the one we specify in the linker script.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists