From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Date: Wed, 19 Jan 2011 22:33:39 +0000 Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Message-Id: <20110119223339.GD23544@Krystal> List-Id: References: <20110119153326.GC11022@Krystal> <20110119.134047.232915743.davem@davemloft.net> <20110119221327.GA23544@Krystal> <20110119.142137.184823805.davem@davemloft.net> In-Reply-To: <20110119.142137.184823805.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Miller Cc: rostedt@goodmis.org, richm@oldelvet.org.uk, 609371@bugs.debian.org, ben@decadent.org.uk, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, fweisbec@gmail.com, mingo@redhat.com * David Miller (davem@davemloft.net) wrote: > From: Mathieu Desnoyers > Date: Wed, 19 Jan 2011 17:13:27 -0500 > > > Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would > > generate a unaligned access for a 32-bit aligned u64. Do you have examples in > > mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK, > > gcc treats u64 as two distinct reads on all 32-bit architectures. > > Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI > specifies that every structure is at least 8 byte aligned. Ah, that's the answer I was looking for, thanks! > > > gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using > > gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, "packed" > > generates aweful code, but that "packed, aligned(4 or 8)" generates pretty > > decent code: > > Amazing, if this works then do it. > > But please document this fully with comments and such :-) I will, I will! ;) So I guess we go for the following. Is it verbose enough ? /* * __u64_packed_aligned: * * Forces gcc to use the u64 type alignment, up-aligning or down-aligning the * target type if necessary. The memory accesses to the target structure are * efficient (does not require bytewise memory accesses) and the atomic pointer * update guarantees required by RCU are kept. u64 is considered as the largest * type that can generate a trap for unaligned accesses (u64 on sparc32 needs to * be aligned on 64-bit). * * Specifying both "packed" and "aligned" generates decent code (without the * bytewise memory accesses generated by simply using "packed"), and forces * gcc to down-align the structure alignment to the alignment of a u64 type. * * This alignment should be used for both structure definitions and declarations * (as *both* the type and variable attribute) when using the "section" * attribute to generate arrays of structures. */ #define __u64_packed_aligned \ __attribute__((__packed__, __aligned__(__alignof__(long long)))) Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755049Ab1ASWdn (ORCPT ); Wed, 19 Jan 2011 17:33:43 -0500 Received: from mail.openrapids.net ([64.15.138.104]:49510 "EHLO blackscsi.openrapids.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754767Ab1ASWdm (ORCPT ); Wed, 19 Jan 2011 17:33:42 -0500 Date: Wed, 19 Jan 2011 17:33:39 -0500 From: Mathieu Desnoyers To: David Miller Cc: rostedt@goodmis.org, richm@oldelvet.org.uk, 609371@bugs.debian.org, ben@decadent.org.uk, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, fweisbec@gmail.com, mingo@redhat.com Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36 Message-ID: <20110119223339.GD23544@Krystal> References: <20110119153326.GC11022@Krystal> <20110119.134047.232915743.davem@davemloft.net> <20110119221327.GA23544@Krystal> <20110119.142137.184823805.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110119.142137.184823805.davem@davemloft.net> X-Editor: vi X-Info: http://www.efficios.com X-Operating-System: Linux/2.6.26-2-686 (i686) X-Uptime: 17:22:06 up 57 days, 3:25, 4 users, load average: 0.00, 0.00, 0.00 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * David Miller (davem@davemloft.net) wrote: > From: Mathieu Desnoyers > Date: Wed, 19 Jan 2011 17:13:27 -0500 > > > Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would > > generate a unaligned access for a 32-bit aligned u64. Do you have examples in > > mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK, > > gcc treats u64 as two distinct reads on all 32-bit architectures. > > Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI > specifies that every structure is at least 8 byte aligned. Ah, that's the answer I was looking for, thanks! > > > gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using > > gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, "packed" > > generates aweful code, but that "packed, aligned(4 or 8)" generates pretty > > decent code: > > Amazing, if this works then do it. > > But please document this fully with comments and such :-) I will, I will! ;) So I guess we go for the following. Is it verbose enough ? /* * __u64_packed_aligned: * * Forces gcc to use the u64 type alignment, up-aligning or down-aligning the * target type if necessary. The memory accesses to the target structure are * efficient (does not require bytewise memory accesses) and the atomic pointer * update guarantees required by RCU are kept. u64 is considered as the largest * type that can generate a trap for unaligned accesses (u64 on sparc32 needs to * be aligned on 64-bit). * * Specifying both "packed" and "aligned" generates decent code (without the * bytewise memory accesses generated by simply using "packed"), and forces * gcc to down-align the structure alignment to the alignment of a u64 type. * * This alignment should be used for both structure definitions and declarations * (as *both* the type and variable attribute) when using the "section" * attribute to generate arrays of structures. */ #define __u64_packed_aligned \ __attribute__((__packed__, __aligned__(__alignof__(long long)))) Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com