[LTP] Pre-release LTP build

[LTP] Pre-release LTP build

[Cyril Hrubis]

Hi!
I've tried to build LTP source for several distributions and as I
expected the support for compiler atomic operations is missing in old
compilers. Particulary gcc-4.1 on x86 (32bit RHEL5) and gcc-3.4 (SLES9)
and older which were released in 2007 and 2006.

The questions is: do we care enough to provide fallback inline assembler?

I would be inclined to say that we don't. So does anybody out there
still uses LTP with a compiler old enough that it does not support
atomic builtins?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Pre-release LTP build

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Sent: Monday, 11 April, 2016 7:23:05 PM
> Subject: [LTP] Pre-release LTP build
> 
> Hi!
> I've tried to build LTP source for several distributions and as I
> expected the support for compiler atomic operations is missing in old
> compilers. Particulary gcc-4.1 on x86 (32bit RHEL5) and gcc-3.4 (SLES9)
> and older which were released in 2007 and 2006.
> 
> The questions is: do we care enough to provide fallback inline assembler?
> 
> I would be inclined to say that we don't. So does anybody out there
> still uses LTP with a compiler old enough that it does not support
> atomic builtins?

I do. At least RHEL5.6 is going to be around for another year.

I have repeatedly built your patch-series on RHEL5.6 x86_64, which works
fine. But as you pointed out 32bit version fails, other arches possibly too.

My first thought was some kind of lock, so we don't have to care
about each architecture separately.

[LTP] Pre-release LTP build

[Cyril Hrubis]

Hi!
> I do. At least RHEL5.6 is going to be around for another year.
> 
> I have repeatedly built your patch-series on RHEL5.6 x86_64, which works
> fine. But as you pointed out 32bit version fails, other arches possibly too.
> 
> My first thought was some kind of lock, so we don't have to care
> about each architecture separately.

I think that easiest solution would be copying the assembler the builtin
produces and using it as a fallback. That would have to be done per
arch, but the rest of the code could be left untouched.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Pre-release LTP build

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Tuesday, 12 April, 2016 10:40:49 AM
> Subject: Re: [LTP] Pre-release LTP build
> 
> Hi!
> > I do. At least RHEL5.6 is going to be around for another year.
> > 
> > I have repeatedly built your patch-series on RHEL5.6 x86_64, which works
> > fine. But as you pointed out 32bit version fails, other arches possibly
> > too.
> > 
> > My first thought was some kind of lock, so we don't have to care
> > about each architecture separately.
> 
> I think that easiest solution would be copying the assembler the builtin
> produces and using it as a fallback. That would have to be done per
> arch, but the rest of the code could be left untouched.

As for RHEL5.6 it's only i386. I was able to compile x86_64, ia64, ppc/ppc64
and s390/s390x with no changes.

Any of these two allow it to compile on x86:
1. -march=i486 (or higher)
2.
diff --git a/lib/tst_atomic.c b/lib/tst_atomic.c
new file mode 100644
index 0000000..601fd6c
--- /dev/null
+++ b/lib/tst_atomic.c
@@ -0,0 +1,8 @@
+#if defined(__i386__)
+unsigned int __sync_add_and_fetch_4(unsigned int *v, unsigned value)
+{
+       register int val = value;
+       __asm__ __volatile__ ( "lock xadd %1,%0" : "=m" (*v), "=r" (val) : "1" (val) : "memory");
+       return val + value;
+}
+#endif

According to gcc docs it should only make external call to above function,
when it's not provided natively, so it works as fallback.

[LTP] Pre-release LTP build

[Cyril Hrubis]

Hi!
> As for RHEL5.6 it's only i386. I was able to compile x86_64, ia64, ppc/ppc64
> and s390/s390x with no changes.
> 
> Any of these two allow it to compile on x86:
> 1. -march=i486 (or higher)
> 2.
> diff --git a/lib/tst_atomic.c b/lib/tst_atomic.c
> new file mode 100644
> index 0000000..601fd6c
> --- /dev/null
> +++ b/lib/tst_atomic.c
> @@ -0,0 +1,8 @@
> +#if defined(__i386__)
> +unsigned int __sync_add_and_fetch_4(unsigned int *v, unsigned value)
> +{
> +       register int val = value;
> +       __asm__ __volatile__ ( "lock xadd %1,%0" : "=m" (*v), "=r" (val) : "1" (val) : "memory");
> +       return val + value;
> +}
> +#endif
> 
> According to gcc docs it should only make external call to above function,
> when it's not provided natively, so it works as fallback.

Accordingly to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115

It does not work with gcc 4.1 when the builtin is returned directly at
the end of the function.

So storing the return value to a variable may fix that as well.

But I would prefer having fallback definition over working around
compiler bugs.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Pre-release LTP build

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Tuesday, 12 April, 2016 2:23:07 PM
> Subject: Re: [LTP] Pre-release LTP build
> 
> Hi!
> > As for RHEL5.6 it's only i386. I was able to compile x86_64, ia64,
> > ppc/ppc64
> > and s390/s390x with no changes.
> > 
> > Any of these two allow it to compile on x86:
> > 1. -march=i486 (or higher)
> > 2.
> > diff --git a/lib/tst_atomic.c b/lib/tst_atomic.c
> > new file mode 100644
> > index 0000000..601fd6c
> > --- /dev/null
> > +++ b/lib/tst_atomic.c
> > @@ -0,0 +1,8 @@
> > +#if defined(__i386__)
> > +unsigned int __sync_add_and_fetch_4(unsigned int *v, unsigned value)
> > +{
> > +       register int val = value;
> > +       __asm__ __volatile__ ( "lock xadd %1,%0" : "=m" (*v), "=r" (val) :
> > "1" (val) : "memory");
> > +       return val + value;
> > +}
> > +#endif
> > 
> > According to gcc docs it should only make external call to above function,
> > when it's not provided natively, so it works as fallback.
> 
> Accordingly to:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
> 
> It does not work with gcc 4.1 when the builtin is returned directly at
> the end of the function.
> 
> So storing the return value to a variable may fix that as well.

It made no difference for me:

../../lib/libltp.a(tst_test.o): In function `tst_atomic_inc':
/root/ltp/lib/../include/tst_atomic.h:23: undefined reference to `__sync_add_and_fetch_4'
/root/ltp/lib/../include/tst_atomic.h:23: undefined reference to `__sync_add_and_fetch_4'
/root/ltp/lib/../include/tst_atomic.h:23: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
make[1]: *** [test01] Error 1
make[1]: Leaving directory `/root/ltp/lib/newlib_tests'
make: *** [all] Error 2

> But I would prefer having fallback definition over working around
> compiler bugs.

Agreed.

[LTP] Pre-release LTP build

[Cyril Hrubis]

Hi!
> > > +++ b/lib/tst_atomic.c
> > > @@ -0,0 +1,8 @@
> > > +#if defined(__i386__)
> > > +unsigned int __sync_add_and_fetch_4(unsigned int *v, unsigned value)
> > > +{
> > > +       register int val = value;
> > > +       __asm__ __volatile__ ( "lock xadd %1,%0" : "=m" (*v), "=r" (val) :
> > > "1" (val) : "memory");
> > > +       return val + value;
> > > +}
> > > +#endif
> > > 
> > > According to gcc docs it should only make external call to above function,
> > > when it's not provided natively, so it works as fallback.

This does not work with gcc-3.3 where no redirection from
__sync_add_and_fetch -> __sync_add_and_fetch_4 happens. I would say that
if we are adding fallback definition it should work with 3.3 as well. So
I guess we should go with configure check and defining
sync_add_and_fetch() directly. We can also print nice #error message in
case that there is no fallback implementation if we decide to go this
way.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] Pre-release LTP build

[Jan Stancek]

----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Tuesday, 12 April, 2016 4:24:50 PM
> Subject: Re: [LTP] Pre-release LTP build
> 
> Hi!
> > > > +++ b/lib/tst_atomic.c
> > > > @@ -0,0 +1,8 @@
> > > > +#if defined(__i386__)
> > > > +unsigned int __sync_add_and_fetch_4(unsigned int *v, unsigned value)
> > > > +{
> > > > +       register int val = value;
> > > > +       __asm__ __volatile__ ( "lock xadd %1,%0" : "=m" (*v), "=r"
> > > > (val) :
> > > > "1" (val) : "memory");
> > > > +       return val + value;
> > > > +}
> > > > +#endif
> > > > 
> > > > According to gcc docs it should only make external call to above
> > > > function,
> > > > when it's not provided natively, so it works as fallback.
> 
> This does not work with gcc-3.3 where no redirection from
> __sync_add_and_fetch -> __sync_add_and_fetch_4 happens. I would say that
> if we are adding fallback definition it should work with 3.3 as well. So
> I guess we should go with configure check and defining
> sync_add_and_fetch() directly. We can also print nice #error message in
> case that there is no fallback implementation if we decide to go this
> way.

I'll post a series that goes this way shortly. I've based it on kernel
atomic_add_return for architectures that are accessible for me. I tested
it only on RHEL5.6 (gcc 4.1.2), which I think is the oldest active
RHEL release at the moment.

What arches do you care about, that have gcc-3.3?

[LTP] Pre-release LTP build

[Cyril Hrubis]

Hi!
> I'll post a series that goes this way shortly. I've based it on kernel
> atomic_add_return for architectures that are accessible for me. I tested
> it only on RHEL5.6 (gcc 4.1.2), which I think is the oldest active
> RHEL release at the moment.
> 
> What arches do you care about, that have gcc-3.3?

I would say that we should work fine on x86 and x86_64. The rest of the
archs are either new ones that does not have this problem or not easy to
get. Well there may be old mac machines that runs Linux just fine but if
you are runing LTP on Linux on ppc mac you should be able to write a few
lines of inline assembler...

-- 
Cyril Hrubis
chrubis@suse.cz