[RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[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

[RFC PATCH 1/1] ARM: Ensure correct structure alignment when using compiler attribute "section"

[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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

[...]

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[sanfilippo]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

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?

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

>>
> 
> 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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Lino Sanfilippo]

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

Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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