Discussion:
[Gc] NEW Patch for libatomic_ops for AIX/PPC
(too old to reply)
GIRARDET, JEAN
2016-09-21 09:26:04 UTC
Permalink
Raw Message
This new patch replaces " libatomic_ops_AO_load.patch" I sent you previously

New patch :
Name : libatomic_ops-7.4.4_AO_HAVE_load.patch
File patched : src/atomic_ops/sysdeps/loadstore/atomic_load.h


It removes the line : #define AO_HAVE_load in file,
Removing this line allows to define the following line in the file "src / atomic_ops / generalize-small.h"

src/atomic_ops/generalize-small.h
#if defined(AO_HAVE_load_acquire) && !defined(AO_HAVE_load)
# define AO_load(addr) AO_load_acquire(addr)
# define AO_HAVE_load
#endif



Regards,
Jean.




$ cat /opt/freeware/src/packages/SOURCES/libatomic_ops-7.4.4_AO_HAVE_load.patch
--- ./src/atomic_ops/sysdeps/loadstore/atomic_load.h.orig 2016-09-21 09:00:25 +0200
+++ ./src/atomic_ops/sysdeps/loadstore/atomic_load.h 2016-09-20 17:23:01 +0200
@@ -34,4 +34,4 @@
/* volatile adds barrier (fence) semantics. */
return *(const AO_t *)addr;
}
-#define AO_HAVE_load
+



From: GIRARDET, JEAN
Sent: Friday, September 16, 2016 11:27 AM
To: 'Ivan Maidanski'; REIX, Tony
Cc: bdwgc
Subject: RE: Re[2]: [Gc] Patch for libatomic_ops for AIX/PPC


Bonjour Ivan,


1. Please explain why is this patch needed? Is this because AIX assembler does not support labels?



Yes, labels are not supported on AIX.



2. As labels are replaced with the exact offset, are the offsets the same for 32-bit and 64-bit modes?



Yes, the length of the instruction (4 characters) is the same for 32/64 bits so the offset are the same for the 2 versions.



3. Please remove asm lines that contain only "\n"
Yes, I will do it for the next patch version for gc and libatomic (patch : libatomic_ops-7.4.4-2_powerpc_h.patch)
I also changed the patch so that it can be applied to both packages (gc and libatomic) without modification.

Regards,
Jean.


From: Ivan Maidanski [mailto:***@mail.ru]
Sent: Thursday, September 15, 2016 12:19 AM
To: REIX, Tony
Cc: bdwgc; GIRARDET, JEAN
Subject: Re[2]: [Gc] Patch for libatomic_ops for AIX/PPC

Hello Tony,

1. Please explain why is this patch needed? Is this because AIX assembler does not support labels?

2. As labels are replaced with the exact offset, are the offsets the same for 32-bit and 64-bit modes?

3. Please remove asm lines that contain only "\n"

Regards,
Ivan
Mon, 12 Sep 2016, 17:59 +03:00 from "REIX, Tony" <***@atos.net<mailto:***@atos.net>>:
Hi Ivan,

Jean was sick last week. He should be back tomorrow.

Here is the patch he worked on and that he delivered with GC on BullFreeware.

Regards,

Tony

Le 03/09/2016 14:58, Ivan Maidanski a écrit :

Hello Tony,

Please send me patch by email.

64-bit variant of libatomic_ops makes sense because e.g. it has ao_malloc which can allocate objects outside 4 GB space.

Regards,
Ivan
--
Fri, 02 Sep 2016, 18:45 +03:00 from "REIX, Tony" <***@atos.net><mailto:***@atos.net>:

Hi Ivan

Hummm We do not use github for now. Not sure if Jean knows how to use it.

R U OK if Jean proposes the patch to you by email ?

About libatomic_ops product:

For now, we were using it inside GC only. I've started to build a .spec file for AIX for building libatomic_op as a RPM.

And I've seen that the test_stack test fails in our environment.

Since the issue is still there though I applied the patch I'm talking about, I guess it is something else.

Jean will study this test_stack test failure asap.

Do you know if a 64bit version of libatomic_ops does make sens ?

For now, we build nearly all our RPMs in 32 & 64 bit modes, and we deliver .so files in .a archives, like AIX does.

Regards,

Tony
../test-driver: line 107: 16515260 IOT/Abort trap (core dumped) "$@" > $log_file 2>&1
FAIL: test_stack
Hello Tony,
You can propose the patch as an attachment but the best way is to raise pull request on github.
AIX is not well tested I guess.
Is the proposed patch related to test_stack fail on ppc -
https://github.com/ivmai/libatomic_ops/issues/15 ?
Regards,
Ivan
--
Fri, 02 Sep 2016, 11:50 +03:00 from "REIX, Tony"
Hi Ivan,
https://github.com/ivmai/libatomic_ops/
https://github.com/ivmai
I see that you manage the github of libtatomic_ops.
My team ports OpenSource packages on AIX 6.1, 7.1, 7.2 .
We (BullFreeware team, Jean) are porting GC v7.6.0 on AIX 6.1 and we had to fix the file:
libatomic_ops/src/atomic_ops/sysdeps/gcc/powerpc.h
from:
libatomic_ops-7.4.4.tar.gz
We have a small patch, changing some ASM instructions that are causing issue on AIX.
1) What is the process for proposing the patch to the maintainers of libatomic_ops ?
2) Up to now, libatomic_ops was delivered by us only inside GC.
It seems to me that delivering it as a individual package, like FedoraCore does, should be useful.
Do you know how deep libatomic_ops has been tested on AIX ?
Thanks
Tony
http://www.bullfreeware.com
_______________________________________________
bdwgc mailing list
***@lists.opendylan.org<mailto:***@lists.opendylan.org>
https://lists.opendylan.org/mailman/listinfo/bdwgc
Ivan Maidanski
2017-04-12 10:50:49 UTC
Permalink
Raw Message
Hello Jean, Tony, Hans,

To Jean and Tony:
Could you please test master of https://github.com/ffabbri4/libatomic_ops on Power 7/8 target? (both with and without configure --disable-atomic-intrinsics option)
If it works for you, I will merge the relevant patches to the upstream.

To Hans: What do you think about https://github.com/ffabbri4/libatomic_ops/commit/6ad98d02ba667e2974553709dee528764688a094 ? (details in https://github.com/ivmai/libatomic_ops/pull/24 )

Regards,
Ivan
Post by GIRARDET, JEAN
 
This new patch replaces " libatomic_ops_AO_load.patch" I sent you previously
 
Name : libatomic_ops-7.4.4_AO_HAVE_load.patch
File patched : src/atomic_ops/sysdeps/loadstore/atomic_load.h
 
 
It removes the line : #define AO_HAVE_load in file,
Removing this line allows to define the following line in the file "src / atomic_ops / generalize-small.h"
 
src/atomic_ops/generalize-small.h
#if defined(AO_HAVE_load_acquire) && !defined(AO_HAVE_load)
# define AO_load(addr) AO_load_acquire(addr)                                         
# define AO_HAVE_load
#endif
 
 
 
Regards,
   Jean.
 
 
 
 
$ cat   /opt/freeware/src/packages/SOURCES/libatomic_ops-7.4.4_AO_HAVE_load.patch
--- ./src/atomic_ops/sysdeps/loadstore/atomic_load.h.orig       2016-09-21 09:00:25 +0200
+++ ./src/atomic_ops/sysdeps/loadstore/atomic_load.h    2016-09-20 17:23:01 +0200
@@ -34,4 +34,4 @@
   /* volatile adds barrier (fence) semantics.                   */
   return *(const AO_t *)addr;
}
-#define AO_HAVE_load
+
 
 
 
From: GIRARDET, JEAN
Sent: Friday, September 16, 2016 11:27 AM
To: 'Ivan Maidanski'; REIX, Tony
Cc: bdwgc
Subject: RE: Re[2]: [Gc] Patch for libatomic_ops for AIX/PPC
 
 
Bonjour Ivan,
 
1.      Please explain why is this patch needed? Is this because AIX assembler does not support labels?
 
Yes, labels are not supported  on AIX.
 
2.      As labels are replaced with the exact offset, are the offsets the same for 32-bit and 64-bit modes?
 
Yes, the length of the instruction (4 characters) is the same for 32/64 bits so the offset are the same for the
2 versions.
Post by GIRARDET, JEAN
 
3.      Please remove asm lines that contain only "\n"
                        Yes, I will do it for the next patch version for gc and libatomic (patch : libatomic_ops-7.4.4-2_powerpc_h.patch)
                        I also changed the patch so that it can be applied to both packages (gc and libatomic) without modification.
 
   Regards,
   Jean.
 
 
Sent: Thursday, September 15, 2016 12:19 AM
To: REIX, Tony
Cc: bdwgc; GIRARDET, JEAN
Subject: Re[2]: [Gc] Patch for libatomic_ops for AIX/PPC
 
Hello Tony,
1. Please explain why is this patch needed? Is this because AIX assembler does not support labels?
2. As labels are replaced with the exact offset, are the offsets the same for 32-bit and 64-bit modes?
3. Please remove asm lines that contain only "\n"
Regards,
Ivan
Hi Ivan,
Jean was sick last week. He should be back tomorrow.
Here is the patch he worked on and that he delivered with GC on BullFreeware.
Regards,
Tony
Post by GIRARDET, JEAN
Hello Tony,
Please send me patch by email.
64-bit variant of libatomic_ops makes sense because e.g. it has ao_malloc which can allocate objects outside 4 GB space.
Regards,
Ivan
--
Hi Ivan
Hummm We do not use github for now. Not sure if Jean knows how to use it.
R U OK if Jean proposes the patch to you by email ?
For now, we were using it inside GC only. I've started to build a .spec file for AIX for building libatomic_op as a RPM.
And I've seen that the  test_stack  test fails in our environment.
Since the issue is still there though I applied the patch I'm talking about, I guess it is something else.
Jean will study this test_stack test failure asap.
Do you know if a 64bit version of libatomic_ops does make sens ?
For now, we build nearly all our RPMs in 32 & 64 bit modes, and we deliver .so files in .a archives, like AIX does.
Regards,
Tony
FAIL: test_stack
Post by GIRARDET, JEAN
Hello Tony,
You can propose the patch as an attachment but the best way is to raise pull request on github.
AIX is not well tested I guess.
Is the proposed patch related to test_stack fail on ppc -
https://github.com/ivmai/libatomic_ops/issues/15 ?
Regards,
Ivan
Post by GIRARDET, JEAN
--
Fri, 02 Sep 2016, 11:50 +03:00 from "REIX, Tony"
Hi Ivan,
https://github.com/ivmai/libatomic_ops/
https://github.com/ivmai
I see that you manage the github of libtatomic_ops.
My team ports OpenSource packages on AIX 6.1, 7.1, 7.2 .
    libatomic_ops/src/atomic_ops/sysdeps/gcc/powerpc.h
    libatomic_ops-7.4.4.tar.gz
We have a small patch, changing some ASM instructions that are causing issue on AIX.
1) What is the process for proposing the patch to the maintainers of libatomic_ops ?
2) Up to now, libatomic_ops was delivered by us only inside GC.
     It seems to me that delivering it as a individual package, like FedoraCore does, should be useful.
     Do you know how deep libatomic_ops has been tested on AIX ?
Thanks
Tony
Post by GIRARDET, JEAN
http://www.bullfreeware.com
 
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
 
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
Loading...