* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-02 10:01 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-02 10:01 UTC (permalink / raw) To: linux, linux-arm-kernel; +Cc: linux-kernel, LinoSanfilippo, Lino Sanfilippo Hi, I came across a problem concerning structure alignment on ARM architectures (in this case the "clock_provider" struct) when structures are placed by means of the "section" compiler attribute. I noticed that with a certain cross compiler one byte padding is inserted in between the structures: <snip> System.map c074cec0 T __clk_of_table c074cec0 t __of_table_fixed_factor_clk c074cec0 T __stop_kprobe_blacklist c074cf88 t __of_table_fixed_clk c074d050 t __of_table_gpio_gate_clk c074d118 t __of_table_mv88f6180_clk c074d1e0 t __of_table_kirkwood_clk c074d2a8 t __clk_of_table_sentinel <snap> As one can see the difference between the adresses are 200 bytes although a clock_provider only is 196 bytes in size. The problem is that in of_clk_init() the __clk_of_table is used as the base of an array. Due to the padding the values in all array elements but the first one are corruped. However with another cross compiler I could not trigger this. So this issue seems to be compiler/linker dependent. With the attached patch applied the layout is correct: c074ce58 T __clk_of_table c074ce58 t __of_table_fixed_factor_clk c074ce58 T __stop_kprobe_blacklist c074cf1c t __of_table_fixed_clk c074cfe0 t __of_table_gpio_gate_clk c074d0a4 t __of_table_mv88f6180_clk c074d168 t __of_table_kirkwood_clk c074d22c t __clk_of_table_sentinel I can trigger the issue with this compiler: wget http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 Note that this issue popped up some years ago for x86 too: http://lkml.iu.edu/hypermail/linux/kernel/0706.2/2552.html I am not sure that this is the right fix though, thats why I sent that as an RFC. Regards, Lino Lino Sanfilippo (1): ARM: Ensure correct structure alignment when using compiler attribute "section" include/linux/compiler.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-02 10:01 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-02 10:01 UTC (permalink / raw) To: linux-arm-kernel Hi, I came across a problem concerning structure alignment on ARM architectures (in this case the "clock_provider" struct) when structures are placed by means of the "section" compiler attribute. I noticed that with a certain cross compiler one byte padding is inserted in between the structures: <snip> System.map c074cec0 T __clk_of_table c074cec0 t __of_table_fixed_factor_clk c074cec0 T __stop_kprobe_blacklist c074cf88 t __of_table_fixed_clk c074d050 t __of_table_gpio_gate_clk c074d118 t __of_table_mv88f6180_clk c074d1e0 t __of_table_kirkwood_clk c074d2a8 t __clk_of_table_sentinel <snap> As one can see the difference between the adresses are 200 bytes although a clock_provider only is 196 bytes in size. The problem is that in of_clk_init() the __clk_of_table is used as the base of an array. Due to the padding the values in all array elements but the first one are corruped. However with another cross compiler I could not trigger this. So this issue seems to be compiler/linker dependent. With the attached patch applied the layout is correct: c074ce58 T __clk_of_table c074ce58 t __of_table_fixed_factor_clk c074ce58 T __stop_kprobe_blacklist c074cf1c t __of_table_fixed_clk c074cfe0 t __of_table_gpio_gate_clk c074d0a4 t __of_table_mv88f6180_clk c074d168 t __of_table_kirkwood_clk c074d22c t __clk_of_table_sentinel I can trigger the issue with this compiler: wget http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 Note that this issue popped up some years ago for x86 too: http://lkml.iu.edu/hypermail/linux/kernel/0706.2/2552.html I am not sure that this is the right fix though, thats why I sent that as an RFC. Regards, Lino Lino Sanfilippo (1): ARM: Ensure correct structure alignment when using compiler attribute "section" include/linux/compiler.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 1/1] ARM: Ensure correct structure alignment when using compiler attribute "section" 2015-03-02 10:01 ` Lino Sanfilippo @ 2015-03-02 10:01 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-02 10:01 UTC (permalink / raw) To: linux, linux-arm-kernel; +Cc: linux-kernel, LinoSanfilippo, Lino Sanfilippo In some cases structures are placed into dedicated sections by means of the "section" compiler attribute and then accessed as elements of an array (e.g when the __clk_of_table is set up which contains all potential clock providers - see CLK_OF_DECLARE). But even if the size of such a structure is a multiple of the processors word size, the linker may decide to use an even greater alignment and thus use padding in between the structures. In this case accessing a structure as an array element is not possible. To avoid such padding and thus allow to access such a structure as an array element enforce an alignment of processor word size by means of the "aligned" attribute. Signed-off-by: Lino Sanfilippo <lsanfil@marvell.com> --- include/linux/compiler.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 33063f8..6f32128 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -371,7 +371,8 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s /* Simple shorthand for a section definition */ #ifndef __section -# define __section(S) __attribute__ ((__section__(#S))) +# define __section(S) __attribute__ ((__section__(#S))) \ + __aligned(sizeof(void *)) #endif #ifndef __visible -- 1.9.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [RFC PATCH 1/1] ARM: Ensure correct structure alignment when using compiler attribute "section" @ 2015-03-02 10:01 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-02 10:01 UTC (permalink / raw) To: linux-arm-kernel In some cases structures are placed into dedicated sections by means of the "section" compiler attribute and then accessed as elements of an array (e.g when the __clk_of_table is set up which contains all potential clock providers - see CLK_OF_DECLARE). But even if the size of such a structure is a multiple of the processors word size, the linker may decide to use an even greater alignment and thus use padding in between the structures. In this case accessing a structure as an array element is not possible. To avoid such padding and thus allow to access such a structure as an array element enforce an alignment of processor word size by means of the "aligned" attribute. Signed-off-by: Lino Sanfilippo <lsanfil@marvell.com> --- include/linux/compiler.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 33063f8..6f32128 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -371,7 +371,8 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s /* Simple shorthand for a section definition */ #ifndef __section -# define __section(S) __attribute__ ((__section__(#S))) +# define __section(S) __attribute__ ((__section__(#S))) \ + __aligned(sizeof(void *)) #endif #ifndef __visible -- 1.9.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-02 10:01 ` Lino Sanfilippo @ 2015-03-03 14:41 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-03 14:41 UTC (permalink / raw) To: Lino Sanfilippo; +Cc: linux, linux-arm-kernel, LinoSanfilippo, linux-kernel On Mon, Mar 02, 2015 at 11:01:41AM +0100, Lino Sanfilippo wrote: > > Hi, > > I came across a problem concerning structure alignment on ARM architectures (in > this case the "clock_provider" struct) when structures are placed by means of the > "section" compiler attribute. I noticed that with a certain cross compiler one > byte padding is inserted in between the structures: > > <snip> System.map > c074cec0 T __clk_of_table > c074cec0 t __of_table_fixed_factor_clk > c074cec0 T __stop_kprobe_blacklist > c074cf88 t __of_table_fixed_clk > c074d050 t __of_table_gpio_gate_clk > c074d118 t __of_table_mv88f6180_clk > c074d1e0 t __of_table_kirkwood_clk > c074d2a8 t __clk_of_table_sentinel > <snap> > > As one can see the difference between the adresses are 200 bytes although a > clock_provider only is 196 bytes in size. > > The problem is that in of_clk_init() the __clk_of_table is used as the base of > an array. Due to the padding the values in all array elements but the first one > are corruped. However with another cross compiler I could not trigger this. So > this issue seems to be compiler/linker dependent. With the attached patch > applied the layout is correct: > > c074ce58 T __clk_of_table > c074ce58 t __of_table_fixed_factor_clk > c074ce58 T __stop_kprobe_blacklist > c074cf1c t __of_table_fixed_clk > c074cfe0 t __of_table_gpio_gate_clk > c074d0a4 t __of_table_mv88f6180_clk > c074d168 t __of_table_kirkwood_clk > c074d22c t __clk_of_table_sentinel > > I can trigger the issue with this compiler: > wget http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 > > Note that this issue popped up some years ago for x86 too: > http://lkml.iu.edu/hypermail/linux/kernel/0706.2/2552.html ^ I think this describes a separate (though related) issue whereby this sequence inside an output section description in the linker script: __foo = .; *(__foo) ... may leave padding between __foo and the included sections. vmlinux.lds.h works around this by doing: . = ALIGN(8); __foo = .; *(__foo) This works so long as none of the included sections requires >8 byte alignment. A slightly cleaner alternative would be to create a separate output section for each array like this: .data.foo : { __foo = .; *(__foo) } ... the alignment for section .data.foo is then the maximum alignment of all of the included sections, and __foo is at that alignment because it's part of that specific output section. That should ensure that there is no padding before the included sections. Switching to this method would involve some churn though -- ALIGN(8) has been pasted all over the place, and there may be bits of asm code that assume an alignment of 8 bytes for some of these arrays even when the compiler does not require it. ... anyway ... For the element _size_ issue, I'm confused. On 32-bit, that structure is clearly 196 bytes in size, with the alignment requirement of void * (4 bytes)... so there's no clear reason why the linker shouldn't be inserting extra padding. I can't reproduce this with my current tools (upstream binutils-2.24, gcc-4.9.2). Can you try to track down where this discrepancy is coming from? i.e., * If you're juggling with multiple kernel trees, make sure there are not differences between them that could be causing this, such as changes to linker scripts or header files that are involved in building these arrays. * See what the input to the assembler looks like, with regard to .align directives. * See what the alignment of the affected sections is in each individual .o file. * See what __alignof__(struct of_device_id) evaluates to. You could also try vanilla upstream versions of the tools, including the upstream ancestors of the affected toolchain (gcc-4.4, binutils-2.20 IIUC) > > I am not sure that this is the right fix though, thats why I sent that as an > RFC. Good try, but the compiler should be marking all those sections with the correct alignment value anyway. Either it isn't, or something else is going wrong somewhere... Cheers ---Dave [...] ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-03 14:41 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-03 14:41 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 02, 2015 at 11:01:41AM +0100, Lino Sanfilippo wrote: > > Hi, > > I came across a problem concerning structure alignment on ARM architectures (in > this case the "clock_provider" struct) when structures are placed by means of the > "section" compiler attribute. I noticed that with a certain cross compiler one > byte padding is inserted in between the structures: > > <snip> System.map > c074cec0 T __clk_of_table > c074cec0 t __of_table_fixed_factor_clk > c074cec0 T __stop_kprobe_blacklist > c074cf88 t __of_table_fixed_clk > c074d050 t __of_table_gpio_gate_clk > c074d118 t __of_table_mv88f6180_clk > c074d1e0 t __of_table_kirkwood_clk > c074d2a8 t __clk_of_table_sentinel > <snap> > > As one can see the difference between the adresses are 200 bytes although a > clock_provider only is 196 bytes in size. > > The problem is that in of_clk_init() the __clk_of_table is used as the base of > an array. Due to the padding the values in all array elements but the first one > are corruped. However with another cross compiler I could not trigger this. So > this issue seems to be compiler/linker dependent. With the attached patch > applied the layout is correct: > > c074ce58 T __clk_of_table > c074ce58 t __of_table_fixed_factor_clk > c074ce58 T __stop_kprobe_blacklist > c074cf1c t __of_table_fixed_clk > c074cfe0 t __of_table_gpio_gate_clk > c074d0a4 t __of_table_mv88f6180_clk > c074d168 t __of_table_kirkwood_clk > c074d22c t __clk_of_table_sentinel > > I can trigger the issue with this compiler: > wget http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 > > Note that this issue popped up some years ago for x86 too: > http://lkml.iu.edu/hypermail/linux/kernel/0706.2/2552.html ^ I think this describes a separate (though related) issue whereby this sequence inside an output section description in the linker script: __foo = .; *(__foo) ... may leave padding between __foo and the included sections. vmlinux.lds.h works around this by doing: . = ALIGN(8); __foo = .; *(__foo) This works so long as none of the included sections requires >8 byte alignment. A slightly cleaner alternative would be to create a separate output section for each array like this: .data.foo : { __foo = .; *(__foo) } ... the alignment for section .data.foo is then the maximum alignment of all of the included sections, and __foo is at that alignment because it's part of that specific output section. That should ensure that there is no padding before the included sections. Switching to this method would involve some churn though -- ALIGN(8) has been pasted all over the place, and there may be bits of asm code that assume an alignment of 8 bytes for some of these arrays even when the compiler does not require it. ... anyway ... For the element _size_ issue, I'm confused. On 32-bit, that structure is clearly 196 bytes in size, with the alignment requirement of void * (4 bytes)... so there's no clear reason why the linker shouldn't be inserting extra padding. I can't reproduce this with my current tools (upstream binutils-2.24, gcc-4.9.2). Can you try to track down where this discrepancy is coming from? i.e., * If you're juggling with multiple kernel trees, make sure there are not differences between them that could be causing this, such as changes to linker scripts or header files that are involved in building these arrays. * See what the input to the assembler looks like, with regard to .align directives. * See what the alignment of the affected sections is in each individual .o file. * See what __alignof__(struct of_device_id) evaluates to. You could also try vanilla upstream versions of the tools, including the upstream ancestors of the affected toolchain (gcc-4.4, binutils-2.20 IIUC) > > I am not sure that this is the right fix though, thats why I sent that as an > RFC. Good try, but the compiler should be marking all those sections with the correct alignment value anyway. Either it isn't, or something else is going wrong somewhere... Cheers ---Dave [...] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-03 14:41 ` Dave Martin @ 2015-03-04 11:40 ` sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: sanfilippo @ 2015-03-04 11:40 UTC (permalink / raw) To: Dave Martin; +Cc: linux, linux-arm-kernel, LinoSanfilippo, linux-kernel On 03.03.2015 15:41, Dave Martin wrote: Dave, thanks for your response. > For the element _size_ issue, I'm confused. On 32-bit, that > structure is clearly 196 bytes in size, with the alignment requirement > of void * (4 bytes)... so there's no clear reason why the linker > shouldn't be inserting extra padding. > > I can't reproduce this with my current tools (upstream binutils-2.24, > gcc-4.9.2). > > > Can you try to track down where this discrepancy is coming from? > > i.e., > > * If you're juggling with multiple kernel trees, make sure there > are not differences between them that could be causing this, such > as changes to linker scripts or header files that are involved > in building these arrays. I can reproduce this with a vanilla kernel (3.19) from kernel.org. What I do is: - configure the kernel with mvebu_v5_defconfig - compile it However this issue occurs (so far) only with this special toolchain: http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 If you like you can try this yourself. I am sure that you will get the same results. I tried the same with three other toolchains but with those the problem did not occur. I also tried other kernel configurations with that "problematic" toolchain, but also the problem did not occur any more. So I think its either a bug in that compiler/linker or the current solution in vmlinux.lds.h does not work correct under some special circumstances. > > * See what the input to the assembler looks like, with regard to > .align directives. > > * See what the alignment of the affected sections is in each individual > .o file. Not sure what exactly I should check here. Could you be a bit more precise? > * See what __alignof__(struct of_device_id) evaluates to. It evaluates to "4" even for the bad case. Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-04 11:40 ` sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: sanfilippo @ 2015-03-04 11:40 UTC (permalink / raw) To: linux-arm-kernel On 03.03.2015 15:41, Dave Martin wrote: Dave, thanks for your response. > For the element _size_ issue, I'm confused. On 32-bit, that > structure is clearly 196 bytes in size, with the alignment requirement > of void * (4 bytes)... so there's no clear reason why the linker > shouldn't be inserting extra padding. > > I can't reproduce this with my current tools (upstream binutils-2.24, > gcc-4.9.2). > > > Can you try to track down where this discrepancy is coming from? > > i.e., > > * If you're juggling with multiple kernel trees, make sure there > are not differences between them that could be causing this, such > as changes to linker scripts or header files that are involved > in building these arrays. I can reproduce this with a vanilla kernel (3.19) from kernel.org. What I do is: - configure the kernel with mvebu_v5_defconfig - compile it However this issue occurs (so far) only with this special toolchain: http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 If you like you can try this yourself. I am sure that you will get the same results. I tried the same with three other toolchains but with those the problem did not occur. I also tried other kernel configurations with that "problematic" toolchain, but also the problem did not occur any more. So I think its either a bug in that compiler/linker or the current solution in vmlinux.lds.h does not work correct under some special circumstances. > > * See what the input to the assembler looks like, with regard to > .align directives. > > * See what the alignment of the affected sections is in each individual > .o file. Not sure what exactly I should check here. Could you be a bit more precise? > * See what __alignof__(struct of_device_id) evaluates to. It evaluates to "4" even for the bad case. Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-04 11:40 ` sanfilippo @ 2015-03-04 14:35 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-04 14:35 UTC (permalink / raw) To: sanfilippo; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On Wed, Mar 04, 2015 at 12:40:34PM +0100, sanfilippo wrote: > On 03.03.2015 15:41, Dave Martin wrote: > > Dave, > > thanks for your response. > > >For the element _size_ issue, I'm confused. On 32-bit, that > >structure is clearly 196 bytes in size, with the alignment requirement > >of void * (4 bytes)... so there's no clear reason why the linker > >shouldn't be inserting extra padding. > > > >I can't reproduce this with my current tools (upstream binutils-2.24, > >gcc-4.9.2). > > > > > >Can you try to track down where this discrepancy is coming from? > > > >i.e., > > > > * If you're juggling with multiple kernel trees, make sure there > > are not differences between them that could be causing this, such > > as changes to linker scripts or header files that are involved > > in building these arrays. > > I can reproduce this with a vanilla kernel (3.19) from kernel.org. > What I do is: > > - configure the kernel with mvebu_v5_defconfig > - compile it > > However this issue occurs (so far) only with this special toolchain: > http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 > > If you like you can try this yourself. I am sure that you will get > the same results. Not really ;) Please see what you can find out first (see below). > > I tried the same with three other toolchains but with those the > problem did not occur. I also tried other kernel configurations with > that "problematic" toolchain, but also the problem did not occur any > more. > > So I think its either a bug in that compiler/linker or the current > solution in vmlinux.lds.h does not work correct under some special > circumstances. > > > > > * See what the input to the assembler looks like, with regard to > > .align directives. > > > > * See what the alignment of the affected sections is in each individual > > .o file. > > Not sure what exactly I should check here. Could you be a bit more precise? > > > * See what __alignof__(struct of_device_id) evaluates to. > > It evaluates to "4" even for the bad case. Try rm drivers/clk/mvebu/kirkwood.o make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o (abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and I'm too lazy to copy-paste command lines...) The compiler will split out the compiled assembly code in kirkwood.s: Look for ".align" directives between the start of the affected section and the start of the next section (next .section directive). Here, we just have .align 2, which is the expected correct value (i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). A different value here may indicate a bug in the compiler, because you observed that gcc _thinks_ that __alignof__ is 4 for the struct in this section even in the failing case. .section __clk_of_table,"a",%progbits .align 2 .type __of_table_mv88f6180_clk, %object .size __of_table_mv88f6180_clk, 196 __of_table_mv88f6180_clk: .space 64 .ascii "marvell,mv88f6180-core-clock\000" .space 99 .word kirkwood_clk_init .type __of_table_kirkwood_clk, %object .size __of_table_kirkwood_clk, 196 __of_table_kirkwood_clk: .space 64 .ascii "marvell,kirkwood-core-clock\000" .space 100 .word kirkwood_clk_init .section .rodata.str1.8,"aMS",%progbits,1 Also try: arm-linux-gnueabi-objdump --headers drivers/clk/mvebu/kirkwood.o Sections: Idx Name Size VMA LMA File off Algn [...] 9 __clk_of_table 00000188 00000000 00000000 00000434 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA The "Algn" column should be 2**2. If it's not, but the assembly code generated by the compiler looks correct, then there may be a bug in the assembler. If the .o file looks correct, it's possible that there is another .o file containing data for this section that specifies a different alignment.o -- try git grep CLK_OF_DECLARE to find the affected files. It's also worth looking at __clk_of_table_end in drivers/clk/clk.o. That gets merged in at the end of the same section, so if its alignment is higher for some reason, that might be causing the problem. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-04 14:35 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-04 14:35 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 04, 2015 at 12:40:34PM +0100, sanfilippo wrote: > On 03.03.2015 15:41, Dave Martin wrote: > > Dave, > > thanks for your response. > > >For the element _size_ issue, I'm confused. On 32-bit, that > >structure is clearly 196 bytes in size, with the alignment requirement > >of void * (4 bytes)... so there's no clear reason why the linker > >shouldn't be inserting extra padding. > > > >I can't reproduce this with my current tools (upstream binutils-2.24, > >gcc-4.9.2). > > > > > >Can you try to track down where this discrepancy is coming from? > > > >i.e., > > > > * If you're juggling with multiple kernel trees, make sure there > > are not differences between them that could be causing this, such > > as changes to linker scripts or header files that are involved > > in building these arrays. > > I can reproduce this with a vanilla kernel (3.19) from kernel.org. > What I do is: > > - configure the kernel with mvebu_v5_defconfig > - compile it > > However this issue occurs (so far) only with this special toolchain: > http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 > > If you like you can try this yourself. I am sure that you will get > the same results. Not really ;) Please see what you can find out first (see below). > > I tried the same with three other toolchains but with those the > problem did not occur. I also tried other kernel configurations with > that "problematic" toolchain, but also the problem did not occur any > more. > > So I think its either a bug in that compiler/linker or the current > solution in vmlinux.lds.h does not work correct under some special > circumstances. > > > > > * See what the input to the assembler looks like, with regard to > > .align directives. > > > > * See what the alignment of the affected sections is in each individual > > .o file. > > Not sure what exactly I should check here. Could you be a bit more precise? > > > * See what __alignof__(struct of_device_id) evaluates to. > > It evaluates to "4" even for the bad case. Try rm drivers/clk/mvebu/kirkwood.o make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o (abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and I'm too lazy to copy-paste command lines...) The compiler will split out the compiled assembly code in kirkwood.s: Look for ".align" directives between the start of the affected section and the start of the next section (next .section directive). Here, we just have .align 2, which is the expected correct value (i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). A different value here may indicate a bug in the compiler, because you observed that gcc _thinks_ that __alignof__ is 4 for the struct in this section even in the failing case. .section __clk_of_table,"a",%progbits .align 2 .type __of_table_mv88f6180_clk, %object .size __of_table_mv88f6180_clk, 196 __of_table_mv88f6180_clk: .space 64 .ascii "marvell,mv88f6180-core-clock\000" .space 99 .word kirkwood_clk_init .type __of_table_kirkwood_clk, %object .size __of_table_kirkwood_clk, 196 __of_table_kirkwood_clk: .space 64 .ascii "marvell,kirkwood-core-clock\000" .space 100 .word kirkwood_clk_init .section .rodata.str1.8,"aMS",%progbits,1 Also try: arm-linux-gnueabi-objdump --headers drivers/clk/mvebu/kirkwood.o Sections: Idx Name Size VMA LMA File off Algn [...] 9 __clk_of_table 00000188 00000000 00000000 00000434 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA The "Algn" column should be 2**2. If it's not, but the assembly code generated by the compiler looks correct, then there may be a bug in the assembler. If the .o file looks correct, it's possible that there is another .o file containing data for this section that specifies a different alignment.o -- try git grep CLK_OF_DECLARE to find the affected files. It's also worth looking at __clk_of_table_end in drivers/clk/clk.o. That gets merged in at the end of the same section, so if its alignment is higher for some reason, that might be causing the problem. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-04 14:35 ` Dave Martin @ 2015-03-04 16:29 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-04 16:29 UTC (permalink / raw) To: Dave Martin; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On 04.03.2015 15:35, Dave Martin wrote: > > Try > > rm drivers/clk/mvebu/kirkwood.o > make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o > > (abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and > I'm too lazy to copy-paste command lines...) > > > The compiler will split out the compiled assembly code in kirkwood.s: > > Look for ".align" directives between the start of the affected section > and the start of the next section (next .section directive). > > Here, we just have .align 2, which is the expected correct value > (i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). > > A different value here may indicate a bug in the compiler, because > you observed that gcc _thinks_ that __alignof__ is 4 for the struct > in this section even in the failing case. Ok, this is the result for the assembly: .section __clk_of_table,"a",%progbits .align 3 .type __of_table_mv88f6180_clk, %object .size __of_table_mv88f6180_clk, 196 __of_table_mv88f6180_clk: .space 64 .ascii "marvell,mv88f6180-core-clock\000" .space 99 .word kirkwood_clk_init .space 4 .type __of_table_kirkwood_clk, %object .size __of_table_kirkwood_clk, 196 __of_table_kirkwood_clk: .space 64 .ascii "marvell,kirkwood-core-clock\000" .space 100 .word kirkwood_clk_init And this is the objdump: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000094 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000008 00000000 00000000 000000c8 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00000000 00000000 00000000 000000d0 2**0 ALLOC 3 .debug_abbrev 0000047a 00000000 00000000 000000d0 2**0 CONTENTS, READONLY, DEBUGGING 4 .debug_info 00002c7d 00000000 00000000 0000054a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 5 .debug_line 000003c7 00000000 00000000 000031c7 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .init.text 00000348 00000000 00000000 00003590 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 7 .ARM.extab.init.text 00000000 00000000 00000000 000038d8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .ARM.exidx.init.text 00000030 00000000 00000000 000038d8 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 9 .ARM.extab 00000010 00000000 00000000 00003908 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .ARM.exidx 00000008 00000000 00000000 00003918 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 11 .rodata 00000040 00000000 00000000 00003920 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 12 __clk_of_table 00000190 00000000 00000000 00003960 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 13 .rodata.str1.8 00000100 00000000 00000000 00003af0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .init.rodata 00000288 00000000 00000000 00003bf0 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 15 .debug_frame 000000b4 00000000 00000000 00003e78 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 16 .debug_loc 000002ef 00000000 00000000 00003f2c 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 17 .debug_pubnames 0000002c 00000000 00000000 0000421b 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 18 .debug_aranges 00000050 00000000 00000000 00004247 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 19 .debug_ranges 00000108 00000000 00000000 00004297 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 20 .debug_str 0000163d 00000000 00000000 0000439f 2**0 CONTENTS, READONLY, DEBUGGING 21 .comment 00000055 00000000 00000000 000059dc 2**0 CONTENTS, READONLY 22 .note.GNU-stack 00000000 00000000 00000000 00005a31 2**0 CONTENTS, READONLY 23 .ARM.attributes 0000002b 00000000 00000000 00005a31 2**0 CONTENTS, READONLY Very interesting. It shows an .align 3 which explains alignment on 8 byte boundaries: c07630f8 T __clk_of_table c07630f8 t __of_table_fixed_factor_clk c07630f8 T __stop_kprobe_blacklist c07631c0 t __of_table_fixed_clk c0763288 t __of_table_gpio_gate_clk c0763350 t __of_table_mv88f6180_clk So this is indeed a compiler bug, right? ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-04 16:29 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-04 16:29 UTC (permalink / raw) To: linux-arm-kernel On 04.03.2015 15:35, Dave Martin wrote: > > Try > > rm drivers/clk/mvebu/kirkwood.o > make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o > > (abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and > I'm too lazy to copy-paste command lines...) > > > The compiler will split out the compiled assembly code in kirkwood.s: > > Look for ".align" directives between the start of the affected section > and the start of the next section (next .section directive). > > Here, we just have .align 2, which is the expected correct value > (i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). > > A different value here may indicate a bug in the compiler, because > you observed that gcc _thinks_ that __alignof__ is 4 for the struct > in this section even in the failing case. Ok, this is the result for the assembly: .section __clk_of_table,"a",%progbits .align 3 .type __of_table_mv88f6180_clk, %object .size __of_table_mv88f6180_clk, 196 __of_table_mv88f6180_clk: .space 64 .ascii "marvell,mv88f6180-core-clock\000" .space 99 .word kirkwood_clk_init .space 4 .type __of_table_kirkwood_clk, %object .size __of_table_kirkwood_clk, 196 __of_table_kirkwood_clk: .space 64 .ascii "marvell,kirkwood-core-clock\000" .space 100 .word kirkwood_clk_init And this is the objdump: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000094 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000008 00000000 00000000 000000c8 2**3 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00000000 00000000 00000000 000000d0 2**0 ALLOC 3 .debug_abbrev 0000047a 00000000 00000000 000000d0 2**0 CONTENTS, READONLY, DEBUGGING 4 .debug_info 00002c7d 00000000 00000000 0000054a 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 5 .debug_line 000003c7 00000000 00000000 000031c7 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 6 .init.text 00000348 00000000 00000000 00003590 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 7 .ARM.extab.init.text 00000000 00000000 00000000 000038d8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .ARM.exidx.init.text 00000030 00000000 00000000 000038d8 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 9 .ARM.extab 00000010 00000000 00000000 00003908 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .ARM.exidx 00000008 00000000 00000000 00003918 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 11 .rodata 00000040 00000000 00000000 00003920 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 12 __clk_of_table 00000190 00000000 00000000 00003960 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 13 .rodata.str1.8 00000100 00000000 00000000 00003af0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .init.rodata 00000288 00000000 00000000 00003bf0 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 15 .debug_frame 000000b4 00000000 00000000 00003e78 2**2 CONTENTS, RELOC, READONLY, DEBUGGING 16 .debug_loc 000002ef 00000000 00000000 00003f2c 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 17 .debug_pubnames 0000002c 00000000 00000000 0000421b 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 18 .debug_aranges 00000050 00000000 00000000 00004247 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 19 .debug_ranges 00000108 00000000 00000000 00004297 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 20 .debug_str 0000163d 00000000 00000000 0000439f 2**0 CONTENTS, READONLY, DEBUGGING 21 .comment 00000055 00000000 00000000 000059dc 2**0 CONTENTS, READONLY 22 .note.GNU-stack 00000000 00000000 00000000 00005a31 2**0 CONTENTS, READONLY 23 .ARM.attributes 0000002b 00000000 00000000 00005a31 2**0 CONTENTS, READONLY Very interesting. It shows an .align 3 which explains alignment on 8 byte boundaries: c07630f8 T __clk_of_table c07630f8 t __of_table_fixed_factor_clk c07630f8 T __stop_kprobe_blacklist c07631c0 t __of_table_fixed_clk c0763288 t __of_table_gpio_gate_clk c0763350 t __of_table_mv88f6180_clk So this is indeed a compiler bug, right? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-04 16:29 ` Lino Sanfilippo @ 2015-03-05 12:26 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 12:26 UTC (permalink / raw) To: Lino Sanfilippo; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On Wed, Mar 04, 2015 at 05:29:14PM +0100, Lino Sanfilippo wrote: > On 04.03.2015 15:35, Dave Martin wrote: > > > > >Try > > > >rm drivers/clk/mvebu/kirkwood.o > >make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o > > > >(abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and > >I'm too lazy to copy-paste command lines...) > > > > > >The compiler will split out the compiled assembly code in kirkwood.s: > > > >Look for ".align" directives between the start of the affected section > >and the start of the next section (next .section directive). > > > >Here, we just have .align 2, which is the expected correct value > >(i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). > > > >A different value here may indicate a bug in the compiler, because > >you observed that gcc _thinks_ that __alignof__ is 4 for the struct > >in this section even in the failing case. > > Ok, this is the result for the assembly: > > .section __clk_of_table,"a",%progbits > .align 3 > .type __of_table_mv88f6180_clk, %object > .size __of_table_mv88f6180_clk, 196 > __of_table_mv88f6180_clk: > .space 64 [...] > Very interesting. It shows an .align 3 which explains alignment on > 8 byte boundaries: > > > c07630f8 T __clk_of_table > c07630f8 t __of_table_fixed_factor_clk > c07630f8 T __stop_kprobe_blacklist > c07631c0 t __of_table_fixed_clk > c0763288 t __of_table_gpio_gate_clk > c0763350 t __of_table_mv88f6180_clk > > So this is indeed a compiler bug, right? It certainly looks like the compiler is causing the issue somehow. Whether this is a bug, a bug-like feature, a configuration issue, or a combination of these is not clear. If you know where to find the toolchain source, it might be worth taking a look. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-05 12:26 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 12:26 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 04, 2015 at 05:29:14PM +0100, Lino Sanfilippo wrote: > On 04.03.2015 15:35, Dave Martin wrote: > > > > >Try > > > >rm drivers/clk/mvebu/kirkwood.o > >make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o > > > >(abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and > >I'm too lazy to copy-paste command lines...) > > > > > >The compiler will split out the compiled assembly code in kirkwood.s: > > > >Look for ".align" directives between the start of the affected section > >and the start of the next section (next .section directive). > > > >Here, we just have .align 2, which is the expected correct value > >(i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary). > > > >A different value here may indicate a bug in the compiler, because > >you observed that gcc _thinks_ that __alignof__ is 4 for the struct > >in this section even in the failing case. > > Ok, this is the result for the assembly: > > .section __clk_of_table,"a",%progbits > .align 3 > .type __of_table_mv88f6180_clk, %object > .size __of_table_mv88f6180_clk, 196 > __of_table_mv88f6180_clk: > .space 64 [...] > Very interesting. It shows an .align 3 which explains alignment on > 8 byte boundaries: > > > c07630f8 T __clk_of_table > c07630f8 t __of_table_fixed_factor_clk > c07630f8 T __stop_kprobe_blacklist > c07631c0 t __of_table_fixed_clk > c0763288 t __of_table_gpio_gate_clk > c0763350 t __of_table_mv88f6180_clk > > So this is indeed a compiler bug, right? It certainly looks like the compiler is causing the issue somehow. Whether this is a bug, a bug-like feature, a configuration issue, or a combination of these is not clear. If you know where to find the toolchain source, it might be worth taking a look. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-05 12:26 ` Dave Martin @ 2015-03-05 13:20 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-05 13:20 UTC (permalink / raw) To: Dave Martin; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On 05.03.2015 13:26, Dave Martin wrote: >> >> So this is indeed a compiler bug, right? > > It certainly looks like the compiler is causing the issue somehow. > > Whether this is a bug, a bug-like feature, a configuration issue, > or a combination of these is not clear. > > If you know where to find the toolchain source, it might be worth > taking a look. The toolchain can be found here: http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 But since it turns out to be a compiler issue I dont know if its worth to be investigated further. I think the best solution to avoid that structure alignment problem is to simply use another toolchain. Dave, I thank you very much for your help and efforts to clarify that this is actually not a bug in the kernel. Thx, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-05 13:20 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-05 13:20 UTC (permalink / raw) To: linux-arm-kernel On 05.03.2015 13:26, Dave Martin wrote: >> >> So this is indeed a compiler bug, right? > > It certainly looks like the compiler is causing the issue somehow. > > Whether this is a bug, a bug-like feature, a configuration issue, > or a combination of these is not clear. > > If you know where to find the toolchain source, it might be worth > taking a look. The toolchain can be found here: http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 But since it turns out to be a compiler issue I dont know if its worth to be investigated further. I think the best solution to avoid that structure alignment problem is to simply use another toolchain. Dave, I thank you very much for your help and efforts to clarify that this is actually not a bug in the kernel. Thx, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-05 13:20 ` Lino Sanfilippo @ 2015-03-05 13:47 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 13:47 UTC (permalink / raw) To: Lino Sanfilippo; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On Thu, Mar 05, 2015 at 02:20:43PM +0100, Lino Sanfilippo wrote: > On 05.03.2015 13:26, Dave Martin wrote: > > >> > >>So this is indeed a compiler bug, right? > > > >It certainly looks like the compiler is causing the issue somehow. > > > >Whether this is a bug, a bug-like feature, a configuration issue, > >or a combination of these is not clear. > > > >If you know where to find the toolchain source, it might be worth > >taking a look. > > The toolchain can be found here: > http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 Source code? That just looks like binaries to me. > But since it turns out to be a compiler issue I dont know if its > worth to be investigated further. I think the best solution to avoid > that structure alignment problem is to simply use another toolchain. Maybe not. Could be worth revisiting if other people report the same problem -- a build-time check that > Dave, I thank you very much for your help and efforts to clarify > that this is actually not a bug in the kernel. No probs. I have wondered whether it's really valid to assume that the linker can paste sections from different objects into a valid array like this. There are other things that already work this way though -- such as the way .init_array/.fini_array are created when building a shared library. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-05 13:47 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 13:47 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 05, 2015 at 02:20:43PM +0100, Lino Sanfilippo wrote: > On 05.03.2015 13:26, Dave Martin wrote: > > >> > >>So this is indeed a compiler bug, right? > > > >It certainly looks like the compiler is causing the issue somehow. > > > >Whether this is a bug, a bug-like feature, a configuration issue, > >or a combination of these is not clear. > > > >If you know where to find the toolchain source, it might be worth > >taking a look. > > The toolchain can be found here: > http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2 Source code? That just looks like binaries to me. > But since it turns out to be a compiler issue I dont know if its > worth to be investigated further. I think the best solution to avoid > that structure alignment problem is to simply use another toolchain. Maybe not. Could be worth revisiting if other people report the same problem -- a build-time check that > Dave, I thank you very much for your help and efforts to clarify > that this is actually not a bug in the kernel. No probs. I have wondered whether it's really valid to assume that the linker can paste sections from different objects into a valid array like this. There are other things that already work this way though -- such as the way .init_array/.fini_array are created when building a shared library. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-05 13:47 ` Dave Martin @ 2015-03-05 15:32 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-05 15:32 UTC (permalink / raw) To: Dave Martin; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On 05.03.2015 14:47, Dave Martin wrote: > > Source code? That just looks like binaries to me. > Oops, youre right, there is no source in that package, sorry. I tried to contact the persons that are maintaining this toolchain and asked for access to the source. Hope I will get a response, soon... Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-05 15:32 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-05 15:32 UTC (permalink / raw) To: linux-arm-kernel On 05.03.2015 14:47, Dave Martin wrote: > > Source code? That just looks like binaries to me. > Oops, youre right, there is no source in that package, sorry. I tried to contact the persons that are maintaining this toolchain and asked for access to the source. Hope I will get a response, soon... Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-05 15:32 ` Lino Sanfilippo @ 2015-03-05 17:33 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 17:33 UTC (permalink / raw) To: Lino Sanfilippo; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On Thu, Mar 05, 2015 at 04:32:28PM +0100, Lino Sanfilippo wrote: > On 05.03.2015 14:47, Dave Martin wrote: > > > > >Source code? That just looks like binaries to me. > > > > Oops, youre right, there is no source in that package, sorry. I > tried to contact the persons that are maintaining this toolchain and > asked for access to the source. Hope I will get a response, soon... OK Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-05 17:33 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-05 17:33 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 05, 2015 at 04:32:28PM +0100, Lino Sanfilippo wrote: > On 05.03.2015 14:47, Dave Martin wrote: > > > > >Source code? That just looks like binaries to me. > > > > Oops, youre right, there is no source in that package, sorry. I > tried to contact the persons that are maintaining this toolchain and > asked for access to the source. Hope I will get a response, soon... OK Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-05 17:33 ` Dave Martin @ 2015-03-06 14:02 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-06 14:02 UTC (permalink / raw) To: Dave Martin; +Cc: LinoSanfilippo, linux, linux-kernel, linux-arm-kernel On 05.03.2015 18:33, Dave Martin wrote: > On Thu, Mar 05, 2015 at 04:32:28PM +0100, Lino Sanfilippo wrote: >> On 05.03.2015 14:47, Dave Martin wrote: >> >>> >>> Source code? That just looks like binaries to me. >>> >> >> Oops, youre right, there is no source in that package, sorry. I >> tried to contact the persons that are maintaining this toolchain and >> asked for access to the source. Hope I will get a response, soon... > > OK > > Cheers > ---Dave > Ok, I got a link to the source now. It can be found here: http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-06 14:02 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-06 14:02 UTC (permalink / raw) To: linux-arm-kernel On 05.03.2015 18:33, Dave Martin wrote: > On Thu, Mar 05, 2015 at 04:32:28PM +0100, Lino Sanfilippo wrote: >> On 05.03.2015 14:47, Dave Martin wrote: >> >>> >>> Source code? That just looks like binaries to me. >>> >> >> Oops, youre right, there is no source in that package, sorry. I >> tried to contact the persons that are maintaining this toolchain and >> asked for access to the source. Hope I will get a response, soon... > > OK > > Cheers > ---Dave > Ok, I got a link to the source now. It can be found here: http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-06 14:02 ` Lino Sanfilippo @ 2015-03-06 18:20 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-06 18:20 UTC (permalink / raw) To: Lino Sanfilippo, Dave Martin; +Cc: linux, linux-kernel, linux-arm-kernel >> > > Ok, I got a link to the source now. It can be found here: > > http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 > Sigh. Just realized that the url is not accessible. Will check that on monday. Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-06 18:20 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-06 18:20 UTC (permalink / raw) To: linux-arm-kernel >> > > Ok, I got a link to the source now. It can be found here: > > http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 > Sigh. Just realized that the url is not accessible. Will check that on monday. Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-06 18:20 ` Lino Sanfilippo @ 2015-03-22 0:56 ` Lino Sanfilippo -1 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-22 0:56 UTC (permalink / raw) To: Lino Sanfilippo, Dave Martin; +Cc: linux, linux-kernel, linux-arm-kernel On 06.03.2015 19:20, Lino Sanfilippo wrote: > >>> >> >> Ok, I got a link to the source now. It can be found here: >> >> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 >> > > > Sigh. Just realized that the url is not accessible. Will check that on > monday. > > Lino > Hello Dave, sorry for my late reply. But I was a few days out of office and had to contact some people which are not in my departement. The outcome is: there is no public repository in which the source code of that special (buggy) toolchain is available any more. There are newer versions already, but even for those the source code is only accessible for customers (thats what I was told). However the responsible developer could confirm that the wrong alignment I initially reported is indeed a bug in the toolchain which now is fixed in the newer versions. I really would have liked to send you the source, but unfortunately I cant. However thanks again for all your help. Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-22 0:56 ` Lino Sanfilippo 0 siblings, 0 replies; 30+ messages in thread From: Lino Sanfilippo @ 2015-03-22 0:56 UTC (permalink / raw) To: linux-arm-kernel On 06.03.2015 19:20, Lino Sanfilippo wrote: > >>> >> >> Ok, I got a link to the source now. It can be found here: >> >> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 >> > > > Sigh. Just realized that the url is not accessible. Will check that on > monday. > > Lino > Hello Dave, sorry for my late reply. But I was a few days out of office and had to contact some people which are not in my departement. The outcome is: there is no public repository in which the source code of that special (buggy) toolchain is available any more. There are newer versions already, but even for those the source code is only accessible for customers (thats what I was told). However the responsible developer could confirm that the wrong alignment I initially reported is indeed a bug in the toolchain which now is fixed in the newer versions. I really would have liked to send you the source, but unfortunately I cant. However thanks again for all your help. Regards, Lino ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" 2015-03-22 0:56 ` Lino Sanfilippo @ 2015-03-24 12:07 ` Dave Martin -1 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-24 12:07 UTC (permalink / raw) To: Lino Sanfilippo; +Cc: Lino Sanfilippo, linux, linux-kernel, linux-arm-kernel On Sun, Mar 22, 2015 at 01:56:10AM +0100, Lino Sanfilippo wrote: > On 06.03.2015 19:20, Lino Sanfilippo wrote: > > > >>> > >> > >> Ok, I got a link to the source now. It can be found here: > >> > >> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 > >> > > > > > > Sigh. Just realized that the url is not accessible. Will check that on > > monday. > > > > Lino > > > > Hello Dave, > > sorry for my late reply. But I was a few days out of office and had to > contact some people which are not in my departement. The outcome is: > there is no public repository in which the source code of that special > (buggy) toolchain is available any more. There are newer versions > already, but even for those the source code is only accessible for > customers (thats what I was told). However the responsible developer (GPL?) > could confirm that the wrong alignment I initially reported is indeed a > bug in the toolchain which now is fixed in the newer versions. > I really would have liked to send you the source, but unfortunately I > cant. However thanks again for all your help. Never mind -- hopefully this issue was caused by something that got fixed upstream meanwhile, or that never went upstream in the first place. Debugging legacy vendor toolchain forks isn't a very interesting pursuit... We can revisit the issue if it comes up again, but I've not heard of any other instances of this type of issue so far. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
* [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" @ 2015-03-24 12:07 ` Dave Martin 0 siblings, 0 replies; 30+ messages in thread From: Dave Martin @ 2015-03-24 12:07 UTC (permalink / raw) To: linux-arm-kernel On Sun, Mar 22, 2015 at 01:56:10AM +0100, Lino Sanfilippo wrote: > On 06.03.2015 19:20, Lino Sanfilippo wrote: > > > >>> > >> > >> Ok, I got a link to the source now. It can be found here: > >> > >> http://tp-lab200/release/gcc/temp/internal/2010q4-113-4.4.5/marvell-gcc.src-2010q4-113.tar.bz2 > >> > > > > > > Sigh. Just realized that the url is not accessible. Will check that on > > monday. > > > > Lino > > > > Hello Dave, > > sorry for my late reply. But I was a few days out of office and had to > contact some people which are not in my departement. The outcome is: > there is no public repository in which the source code of that special > (buggy) toolchain is available any more. There are newer versions > already, but even for those the source code is only accessible for > customers (thats what I was told). However the responsible developer (GPL?) > could confirm that the wrong alignment I initially reported is indeed a > bug in the toolchain which now is fixed in the newer versions. > I really would have liked to send you the source, but unfortunately I > cant. However thanks again for all your help. Never mind -- hopefully this issue was caused by something that got fixed upstream meanwhile, or that never went upstream in the first place. Debugging legacy vendor toolchain forks isn't a very interesting pursuit... We can revisit the issue if it comes up again, but I've not heard of any other instances of this type of issue so far. Cheers ---Dave ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-03-24 12:07 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-02 10:01 [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" Lino Sanfilippo 2015-03-02 10:01 ` Lino Sanfilippo 2015-03-02 10:01 ` [RFC PATCH 1/1] ARM: Ensure correct structure alignment when using " Lino Sanfilippo 2015-03-02 10:01 ` Lino Sanfilippo 2015-03-03 14:41 ` [RFC PATCH 0/1] Wrong structure alignment due to " Dave Martin 2015-03-03 14:41 ` Dave Martin 2015-03-04 11:40 ` sanfilippo 2015-03-04 11:40 ` sanfilippo 2015-03-04 14:35 ` Dave Martin 2015-03-04 14:35 ` Dave Martin 2015-03-04 16:29 ` Lino Sanfilippo 2015-03-04 16:29 ` Lino Sanfilippo 2015-03-05 12:26 ` Dave Martin 2015-03-05 12:26 ` Dave Martin 2015-03-05 13:20 ` Lino Sanfilippo 2015-03-05 13:20 ` Lino Sanfilippo 2015-03-05 13:47 ` Dave Martin 2015-03-05 13:47 ` Dave Martin 2015-03-05 15:32 ` Lino Sanfilippo 2015-03-05 15:32 ` Lino Sanfilippo 2015-03-05 17:33 ` Dave Martin 2015-03-05 17:33 ` Dave Martin 2015-03-06 14:02 ` Lino Sanfilippo 2015-03-06 14:02 ` Lino Sanfilippo 2015-03-06 18:20 ` Lino Sanfilippo 2015-03-06 18:20 ` Lino Sanfilippo 2015-03-22 0:56 ` Lino Sanfilippo 2015-03-22 0:56 ` Lino Sanfilippo 2015-03-24 12:07 ` Dave Martin 2015-03-24 12:07 ` Dave Martin
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.