[parisc-linux] spinlock align code triggering bug in gcc?

[parisc-linux] spinlock align code triggering bug in gcc?

[Randolph Chung]

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

I'm not yet 100% sure about this one, but it seems like with the new
self-aligning spinlock code in the kernel, if you build the kernel with
hppa64-linux-gcc 3.3.3, the kernel generates incorrectly aligned code
when you bulid with -O2. You see something like this...

legolas[11:47] linux-2.6% make drivers/block/loop.o
  CC      drivers/block/loop.o
{standard input}: Assembler messages:
{standard input}:3701: Error: Field not properly aligned [8] (-183).
{standard input}:3701: Error: Invalid operands
make[1]: *** [drivers/block/loop.o] Error 1
make: *** [drivers/block/loop.o] Error 2

this does not happen with the 32-bit gcc-3.3.3. also with -O1 it is ok.
It looks like while gcc tries to inline all the spinlock stuff it gets
confused about the offsets? The attached test case illustrates the
problem. If you build with:

hppa64-linux-gcc -O2 -c foo.c, you'll get the same kind of error.

can someone check this against other versions of gcc? i cannot reach
gcc-bugzilla right now...

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

[-- Attachment #2: foo.c --]
[-- Type: text/x-csrc, Size: 1700 bytes --]

#define __PA_LDCW_ALIGNMENT 16
#define __ldcw_align(a) ({ \
  unsigned long __ret = (unsigned long) a;                              \
  __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) & ~(__PA_LDCW_ALIGNMENT - 1); \
  (volatile unsigned int *) __ret;                                      \
})

#define __ldcw(a) ({ \
        unsigned __ret; \
        __asm__ __volatile__("ldcw 0(%1),%0" : "=r" (__ret) : "r" (a)); \
        __ret; \
})

typedef struct {
  volatile unsigned int lock[4];
} spinlock_t;

struct semaphore
{
  spinlock_t sentry;
  int count;
};

struct loop_device
{
  struct loop_func_table *lo_encryption;
  struct semaphore lo_ctl_mutex;
};

static int max_loop = 8;
static struct loop_device *loop_dev;

void __down (struct semaphore *sem);
void __up (struct semaphore *sem);

static inline void _raw_spin_lock (spinlock_t * x)
{
  volatile unsigned int *a = __ldcw_align(x);

  while (__ldcw(a) == 0)
    while (*a == 0);
}

static inline void _raw_spin_unlock (spinlock_t * x)
{
  volatile unsigned int *a = __ldcw_align(x);
  *a = 1;
}

inline void down (struct semaphore *sem)
{
  _raw_spin_lock (&sem->sentry);
  if (sem->count > 0) { sem->count--; }
  else { __down (sem); }
  _raw_spin_unlock (&sem->sentry);
}

inline void up (struct semaphore *sem)
{
  _raw_spin_lock (&sem->sentry);
  if (sem->count < 0) { __up (sem); }
  else { sem->count++; }
  _raw_spin_unlock (&sem->sentry);
}

int
loop_unregister_transfer (int number)
{
  struct loop_device *lo = &loop_dev[0];

  for (lo = &loop_dev[0]; lo < &loop_dev[max_loop]; lo++)
    {
      down (&lo->lo_ctl_mutex);

      if (lo->lo_encryption == 0)
	loop_release_xfer (lo);

      up (&lo->lo_ctl_mutex);
    }

  return 0;
}

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[Thibaut VARENE]

On Sun, 28 Mar 2004 12:32:11 -0800
"Randolph Chung" <randolph@tausq.org> wrote:

> 
> can someone check this against other versions of gcc? i cannot reach
> gcc-bugzilla right now...
> 

[varenet@npyu ~]% hppa64-linux-gcc -O2 -c foo.c
[varenet@npyu ~]% ls foo*
foo.c foo.o
[varenet@npyu ~]% hppa64-linux-gcc -v
Reading specs from
/usr/local/palinux/lib/gcc-lib/hppa64-linux/3.0.4/specs Configured with:
/Users/varenet/palinux/xc/src/gcc/configure
--host=powerpc-apple-darwin6.1 --build=powerpc-apple-darwin6.1
--target=hppa64-linux --disable-shared --disable-nls
--enable-languages=c --prefix=/usr/local/palinux Thread model: single
gcc version 3.0.4

Good old 3.0.4 seems pretty reliable ;)

HTH,


Thibaut VARENE
The PA/Linux ESIEE Team
http://www.pateam.org/

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[John David Anglin]

> I'm not yet 100% sure about this one, but it seems like with the new
> self-aligning spinlock code in the kernel, if you build the kernel with
> hppa64-linux-gcc 3.3.3, the kernel generates incorrectly aligned code
> when you bulid with -O2. You see something like this...
> 
> legolas[11:47] linux-2.6% make drivers/block/loop.o
>   CC      drivers/block/loop.o
> {standard input}: Assembler messages:
> {standard input}:3701: Error: Field not properly aligned [8] (-183).
> {standard input}:3701: Error: Invalid operands

Take a look at the assembler output for the above line.

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

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[John David Anglin]

> > I'm not yet 100% sure about this one, but it seems like with the new
> > self-aligning spinlock code in the kernel, if you build the kernel with
> > hppa64-linux-gcc 3.3.3, the kernel generates incorrectly aligned code
> > when you bulid with -O2. You see something like this...
> > 
> > legolas[11:47] linux-2.6% make drivers/block/loop.o
> >   CC      drivers/block/loop.o
> > {standard input}: Assembler messages:
> > {standard input}:3701: Error: Field not properly aligned [8] (-183).
> > {standard input}:3701: Error: Invalid operands
> 
> Take a look at the assembler output for the above line.

I think this is a coding problem.

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

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[John David Anglin]

> > > {standard input}:3701: Error: Field not properly aligned [8] (-183).
> > > {standard input}:3701: Error: Invalid operands
> > 
> > Take a look at the assembler output for the above line.
> 
> i did, it's a "ldd -183(%r3), %rN" (i don't remember the target register
> right now)

It's the "183" that's the problem.  Can you see where that is coming from?

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

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[Randolph Chung]

> > legolas[11:47] linux-2.6% make drivers/block/loop.o
> >   CC      drivers/block/loop.o
> > {standard input}: Assembler messages:
> > {standard input}:3701: Error: Field not properly aligned [8] (-183).
> > {standard input}:3701: Error: Invalid operands
> 
> Take a look at the assembler output for the above line.

i did, it's a "ldd -183(%r3), %rN" (i don't remember the target register
right now)

with -g it is pointing to the if () comparision inside the function. but
removing the up()/down() calls makes the error go away. removing the
loop and making it only operate on loop_dev[0] also makes the error go
away.

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

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[Randolph Chung]

> I think this is a coding problem.

that's what i thought too initially, but there are no special things 
in the structure that makes it unaligned. pls take a look at the test 
program i attached... the structure only has a spinlock, an int and a 
pointer.  where the heck does it get 183 from (or 23 in the test 
program)? :) i'm guessing it inlined the __ldcw_align() and did some 
constant folding to do the alignment and then the offset becomes wrong?

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

Re: [parisc-linux] spinlock align code triggering bug in gcc?

[John David Anglin]

> pointer.  where the heck does it get 183 from (or 23 in the test 
> program)? :) i'm guessing it inlined the __ldcw_align() and did some 
> constant folding to do the alignment and then the offset becomes wrong?

23 = 8 + 15.  The 15 is from ldcw align.  Don't know why we are using
this value in a ldd.  I think the ldcw is aligned ok.

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