Allow to compile on archs without atomic support
cover Allow to compile on archs without atomic support
Hi,
I know as this has quite low priority (benefit only people with old compilers and archs), but why not to give a chance them to have at least something from LTP?
Quite a lot of tests it's working, affected are only tests using threads on new API or fuzzy synchronization and counting results for tests using new api.
Kind regards,
Petr
Petr Vorel (2):
tst_atomic.h: Allow to compile on archs without atomic support lib/tst_test.c: Don't print results on archs without atomic
include/tst_atomic.h | 31 +++++++++++++++++++++++++++++-- lib/tst_test.c | 4 ++++ 2 files changed, 33 insertions(+), 2 deletions(-)
Signature · 1 line
2.15.1
RFC PATCH 1/2 tst_atomic.h: Allow to compile on archs without atomic support
Some archs without atomic support in compiler and without our own implementation can now benefit with at least having tests which don't need atomic support.
--- include/tst_atomic.h | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-)
include/tst_atomic.h +29 -2
@@ -61,7 +61,11 @@#ifndef TST_ATOMIC_H__ #define TST_ATOMIC_H__ +#include <stdlib.h> +#include <stdio.h> +#include "config.h" +#include "tst_res_flags.h" #if HAVE_ATOMIC_MEMORY_MODEL ==1 static inline int tst_atomic_add_return (int i,int *v)
@@ -309,8 +313,31 @@ static inline int tst_atomic_add_return(int i, int *v) }#else /* HAVE_SYNC_ADD_AND_FETCH == 1 */ -# error Your compiler does not provide __atomic_add_fetch, __sync_add_and_fetch \ - and an LTP implementation is missing for your architecture. +# define LTP_NO_ATOMIC "WARNING: Your compiler does not provide __atomic_add_fetch, " \ + "__sync_add_and_fetch and an LTP implementation is missing for your architecture. " \ + "Tests using atomic operations (e.g. using threads on new API or fuzzy synchronization) will not work.\n" + +# warning Your compiler does not provide __atomic_add_fetch \ + __sync_add_and_fetch and an LTP implementation is missing for your architecture. \ + Tests using atomic operations (e.g. using threads on new API or fuzzy synchronization) will not work. + +static inline int tst_atomic_add_return(int i LTP_ATTRIBUTE_UNUSED, int *v LTP_ATTRIBUTE_UNUSED) +{ +printf (LTP_NO_ATOMIC ); +exit (TCONF ); +} + +static inline int tst_atomic_load(int *v LTP_ATTRIBUTE_UNUSED) +{ +printf (LTP_NO_ATOMIC ); +exit (TCONF ); +} + +static inline void tst_atomic_store(int i LTP_ATTRIBUTE_UNUSED, int *v LTP_ATTRIBUTE_UNUSED) +{ +printf (LTP_NO_ATOMIC ); +exit (TCONF ); +}#endif #ifdef LTP_USE_GENERIC_LOAD_STORE_ASM
Signature · 1 line
2.15.1
RFC PATCH 2/2 lib/tst_test.c: Don't print results on archs without atomic
In reply to Petr Vorel--- lib/tst_test.c | 4 ++++ 1 file changed, 4 insertions(+)
lib/tst_test.c +4 -0
@@ -574,6 +574,7 @@ int tst_parse_float(const char *str, float *val, float min, float max)static void do_exit (int ret) {if (results) { +#ifndef LTP_NO_ATOMIC printf ("\nSummary:\n" );printf ("passed %d\n" , results->passed);printf ("failed %d\n" , results->failed);
@@ -588,6 +589,9 @@ static void do_exit(int ret)if (results->warnings) ret |=TWARN ; +#else +printf ("WARNING: Results not counted due missing atomic support.\n" ); +#endif }do_cleanup ();
Signature · 1 line
2.15.1
cover Allow to compile on archs without atomic support
In reply to Petr Vorel----- Original Message -----
Quoted 1 line
Hi,
Hi,
Quoted 4 lines
I know as this has quite low priority (benefit only people with old compilers and archs), but why not to give a chance them to have at least something from LTP?
Compiler shouldn't matter, we have fallbacks.
So I assume this concerns only some architectures we currently don't support.
Quoted 3 lines
Quite a lot of tests it's working, affected are only tests using threads on new API or fuzzy synchronization and counting results for tests using new api.
What if we made general implementation with some locking? It would be slower, but I think we don't use atomics that much for it to matter.
Regards,
Jan
cover Allow to compile on archs without atomic support
Hi Jan,
thanks for your comments.
Quoted 6 lines
Quoted 3 lines
I know as this has quite low priority (benefit only people with old compilers and archs), but why not to give a chance them to have at least something from LTP?
Compiler shouldn't matter, we have fallbacks.
So I assume this concerns only some architectures we currently don't support.
Yes.
Quoted 6 lines
Quoted 3 lines
Quite a lot of tests it's working, affected are only tests using threads on new API or fuzzy synchronization and counting results for tests using new api.
What if we made general implementation with some locking? It would be slower, but I think we don't use atomics that much for it to matter.
Makes sense. I'll implement it.
Quoted 2 lines
Regards,
Jan
Kind regards,
Petr
cover Allow to compile on archs without atomic support
In reply to Jan StancekHi!
Quoted 2 lines
What if we made general implementation with some locking? It would be slower, but I think we don't use atomics that much for it to matter.
Atomic increment was easiest way how to make the test library thread safe I wasn't concerned with speed at all. But that is not true for the CVE tests which use atomic operation to synchronize threads to trigger races.
Signature · 2 lines
Cyril Hrubis [email protected]
cover Allow to compile on archs without atomic support
Hi,
Quoted 7 lines
Quoted 2 lines
What if we made general implementation with some locking? It would be slower, but I think we don't use atomics that much for it to matter.
Atomic increment was easiest way how to make the test library thread safe I wasn't concerned with speed at all. But that is not true for the CVE tests which use atomic operation to synchronize threads to trigger races.
That's why I implemented it in v1 as simple exit(). So are we ok that CVE tests will probably be failing / taking so long?
Thank you both, for considering it, as I know it's only corner case.
Kind regards,
Petr