[parisc-linux] gcc-3.[02] alignment problem

[parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
(3.0.4 or 3.2) gives:

tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
{standard input}: Assembler messages:
{standard input}:138: Error: Field not properly aligned [8] (44).
{standard input}:138: Error: Invalid operands
{standard input}:609: Error: Field not properly aligned [8] (44).
{standard input}:609: Error: Invalid operands
{standard input}:707: Error: Field not properly aligned [8] (44).
{standard input}:707: Error: Invalid operands

preprocessed source attached.

(incidentally, we also see this while building glibc...)

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

[parisc-linux] Re: gcc-3.[02] alignment problem

[Randolph Chung]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

> preprocessed source attached.

really attached this time <sigh>

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

[-- Attachment #2: tcp_diag.i.gz --]
[-- Type: application/octet-stream, Size: 92238 bytes --]

[parisc-linux] Re: gcc-3.[02] alignment problem

[Randolph Chung]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

> preprocessed source attached.

really attached this time <sigh>

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

[-- Attachment #2: tcp_diag.i.gz --]
[-- Type: application/octet-stream, Size: 92238 bytes --]

Re: [parisc-linux] gcc-3.[02] alignment problem

[Alan Cox]

On Tue, 2002-07-16 at 06:00, Randolph Chung wrote:
> Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
> (3.0.4 or 3.2) gives:
> 
> tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
> {standard input}: Assembler messages:
> {standard input}:138: Error: Field not properly aligned [8] (44).
> {standard input}:138: Error: Invalid operands

The pa-risc tree has a disgusting hack to work around this. Its one of
the bits I have down in the "vomit grade" pile of bits to look into
during the rest of the merge.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Alan Cox]

On Tue, 2002-07-16 at 06:00, Randolph Chung wrote:
> Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
> (3.0.4 or 3.2) gives:
> 
> tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
> {standard input}: Assembler messages:
> {standard input}:138: Error: Field not properly aligned [8] (44).
> {standard input}:138: Error: Invalid operands

The pa-risc tree has a disgusting hack to work around this. Its one of
the bits I have down in the "vomit grade" pile of bits to look into
during the rest of the merge.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Carlos O'Donell]

> Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
> (3.0.4 or 3.2) gives:
> 
> tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
> {standard input}: Assembler messages:
> {standard input}:138: Error: Field not properly aligned [8] (44).
> {standard input}:138: Error: Invalid operands
> {standard input}:609: Error: Field not properly aligned [8] (44).
> {standard input}:609: Error: Invalid operands
> {standard input}:707: Error: Field not properly aligned [8] (44).
> {standard input}:707: Error: Invalid operands
> 
> preprocessed source attached.
> 
> (incidentally, we also see this while building glibc...)
> 
> randolph

Preprocessed source attached?

Remember we ran into this when building glibc at OLS.... and
we sat there scratching our heads. I'm pretty sure this was the
reason for the hppa-align.dpatch that is part of debianzed gcc?

Randolph: There is a forward email inside the dpatch that says
you were going to try get this patch upstream... ? :)
(gcc 3.0.4 ./debian/patches/hppa-align.dpatch)

c.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> Preprocessed source attached?

I forgot it the first time, tried to send it again, but the source was
too large and it got stopped for moderation...

> Remember we ran into this when building glibc at OLS.... and
> we sat there scratching our heads. I'm pretty sure this was the
> reason for the hppa-align.dpatch that is part of debianzed gcc?

the hppa-align patch is for a different problem aiui, it's so that we
don't do multiple ldcw's on the same cache line. 

in any case, 3.0.4 (which has this patch) gives the same error.

> Randolph: There is a forward email inside the dpatch that says
> you were going to try get this patch upstream... ? :)
> (gcc 3.0.4 ./debian/patches/hppa-align.dpatch)

I've tried, but the gcc folks have put in a different mechanism to do
this, so the patch needs to be reworked, and i haven't gotten back to it
yet.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
> (3.0.4 or 3.2) gives:
> 
> tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
> {standard input}: Assembler messages:
> {standard input}:138: Error: Field not properly aligned [8] (44).
> {standard input}:138: Error: Invalid operands
> {standard input}:609: Error: Field not properly aligned [8] (44).
> {standard input}:609: Error: Invalid operands
> {standard input}:707: Error: Field not properly aligned [8] (44).
> {standard input}:707: Error: Invalid operands

These messages are coming from the assembler (remove "-pipe").  The
first is from "std %r4,44(%r3)".  The offset "44" is not correct for
a store double.  This is probably a problem with pointer arithmetic
in the source.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
> (3.0.4 or 3.2) gives:
> 
> tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
> {standard input}: Assembler messages:
> {standard input}:138: Error: Field not properly aligned [8] (44).
> {standard input}:138: Error: Invalid operands
> {standard input}:609: Error: Field not properly aligned [8] (44).
> {standard input}:609: Error: Invalid operands
> {standard input}:707: Error: Field not properly aligned [8] (44).
> {standard input}:707: Error: Invalid operands

These messages are coming from the assembler (remove "-pipe").  The
first is from "std %r4,44(%r3)".  The offset "44" is not correct for
a store double.  This is probably a problem with pointer arithmetic
in the source.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

[parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

Compiling the linux kernel (2.4.19-rc1-ac5) with hppa64-linux-gcc 
(3.0.4 or 3.2) gives:

tausq@a500:~/src/linux-2.4.19-rc1/net/ipv4$ hppa64-linux-gcc -D__KERNEL__ -I/home/tausq/src/linux-2.4.19-rc1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa64-linux/3.0/include -DKBUILD_BASENAME=tcp_diag  -c -o tcp_diag.o tcp_diag.c
{standard input}: Assembler messages:
{standard input}:138: Error: Field not properly aligned [8] (44).
{standard input}:138: Error: Invalid operands
{standard input}:609: Error: Field not properly aligned [8] (44).
{standard input}:609: Error: Invalid operands
{standard input}:707: Error: Field not properly aligned [8] (44).
{standard input}:707: Error: Invalid operands

preprocessed source attached.

(incidentally, we also see this while building glibc...)

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> These messages are coming from the assembler (remove "-pipe").  The
> first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> a store double.  This is probably a problem with pointer arithmetic
> in the source.

Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> These messages are coming from the assembler (remove "-pipe").  The
> first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> a store double.  This is probably a problem with pointer arithmetic
> in the source.

Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe").  The
> > first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> > a store double.  This is probably a problem with pointer arithmetic
> > in the source.
> 
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
        __u32   tcpdiag_cookie[2]; 
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
        *((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
            sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't.... 

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
        char * parisc_hack_to_align_tcpdiag_cookie;
#endif
        __u32   tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[Matthew Wilcox]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };

> why is the offset of tcpdiag_cookie[0] 44 and not 40?

0	tcpdiag_sport
2	tcpdiag_dport
4	tcpdiag_src
20	tcpdiag_dst
36	tcpdiag_if
40	tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
> 
> 0	tcpdiag_sport
> 2	tcpdiag_dport
> 4	tcpdiag_src
> 20	tcpdiag_dst
> 36	tcpdiag_if
> 40	tcpdiag_cookie
> 
> hmm.. worth checking that dport is at offset 2, not offset 4?

oic, it's embedded inside another structure:

struct tcpdiagmsg
{
        __u8    tcpdiag_family;
        __u8    tcpdiag_state;
        __u8    tcpdiag_timer;
        __u8    tcpdiag_retrans;

        struct tcpdiag_sockid id;

        __u32   tcpdiag_expires;
        __u32   tcpdiag_rqueue;
        __u32   tcpdiag_wqueue;
        __u32   tcpdiag_uid;
        __u32   tcpdiag_inode;
};

that's why it's 44...

randolph

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
> 
> 0	tcpdiag_sport
> 2	tcpdiag_dport
> 4	tcpdiag_src
> 20	tcpdiag_dst
> 36	tcpdiag_if
> 40	tcpdiag_cookie
> 
> hmm.. worth checking that dport is at offset 2, not offset 4?

oic, it's embedded inside another structure:

struct tcpdiagmsg
{
        __u8    tcpdiag_family;
        __u8    tcpdiag_state;
        __u8    tcpdiag_timer;
        __u8    tcpdiag_retrans;

        struct tcpdiag_sockid id;

        __u32   tcpdiag_expires;
        __u32   tcpdiag_rqueue;
        __u32   tcpdiag_wqueue;
        __u32   tcpdiag_uid;
        __u32   tcpdiag_inode;
};

that's why it's 44...

randolph

Re: [parisc-linux] gcc-3.[02] alignment problem

[Matthew Wilcox]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };

> why is the offset of tcpdiag_cookie[0] 44 and not 40?

0	tcpdiag_sport
2	tcpdiag_dport
4	tcpdiag_src
20	tcpdiag_dst
36	tcpdiag_if
40	tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Richard Henderson]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> 
> the code goes on to do:
>         *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
>             sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

This is absolutely awful.

> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
>         char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
>         __u32   tcpdiag_cookie[2];

An only marginally better fix is

	__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~

Re: [parisc-linux] gcc-3.[02] alignment problem

[Richard Henderson]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> 
> the code goes on to do:
>         *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
>             sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

This is absolutely awful.

> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
>         char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
>         __u32   tcpdiag_cookie[2];

An only marginally better fix is

	__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe").  The
> > first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> > a store double.  This is probably a problem with pointer arithmetic
> > in the source.
> 
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
        __u32   tcpdiag_cookie[2]; 
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
        *((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
            sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't.... 

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
        char * parisc_hack_to_align_tcpdiag_cookie;
#endif
        __u32   tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/